RFC1475 日本語訳
1475 TP/IX: The Next Internet. R. Ullmann. June 1993. (Format: TXT=77854 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group R. Ullmann
Request for Comments: 1475 Process Software Corporation
June 1993
コメントを求めるワーキンググループR.ウルマン要求をネットワークでつないでください: 1475はソフトウェア社の1993年6月に処理されます。
TP/IX: The Next Internet
TP/IX: 次のインターネット
Status of this Memo
このMemoの状態
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard. Discussion and suggestions for improvement are requested. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 それはインターネット標準を指定しません。 議論と改善提案は要求されています。 このプロトコルの標準化状態と状態の「IABの公式のプロトコル標準」の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
The first version of this memo, describing a possible next generation of Internet protocols, was written by the present author in the summer and fall of 1989, and circulated informally, including to the IESG, in December 1989. A further informal note on the addressing, called "Toasternet Part II", was circulated on the IETF mail list during March of 1992.
インターネットプロトコルの可能な次世代について説明して、このメモの最初のバージョンは、夏、1989年秋に現在の作者によって書かれて、非公式に循環しました、IESGに包含して、1989年12月に。 「ToasternetパートII」と呼ばれるアドレシングに関するさらなる非公式の注は1992年3月にIETFメール・リストを循環しました。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . 3 1.1 Objectives . . . . . . . . . . . . . . . . . . . . 5 1.2 Philosophy . . . . . . . . . . . . . . . . . . . . 6 2. Internet numbers . . . . . . . . . . . . . . . . . . 6 2.1 Is 64 Bits Enough? . . . . . . . . . . . . . . . . 6 2.2 Why version 7? . . . . . . . . . . . . . . . . . . 7 2.3 The version 7 IP address . . . . . . . . . . . . . 7 2.4 AD numbers . . . . . . . . . . . . . . . . . . . . 8 2.5 Mapping of version 4 numbers . . . . . . . . . . . 8 3. IP: Internet datagram protocol . . . . . . . . . . . 9 3.1 IP datagram header format . . . . . . . . . . . . 10 3.1.1 Version . . . . . . . . . . . . . . . . . . . . 10 3.1.2 Header length . . . . . . . . . . . . . . . . . 10 3.1.3 Time to live . . . . . . . . . . . . . . . . . 10 3.1.4 Total datagram length . . . . . . . . . . . . . 11 3.1.5 Forward route identifier . . . . . . . . . . . 11 3.1.6 Destination . . . . . . . . . . . . . . . . . . 11 3.1.7 Source . . . . . . . . . . . . . . . . . . . . 11 3.1.8 Protocol . . . . . . . . . . . . . . . . . . . 11 3.1.9 Checksum . . . . . . . . . . . . . . . . . . . 11 3.1.10 Options . . . . . . . . . . . . . . . . . . . . 11
1. 序論. . . . . . . . . . . . . . . . . . . . 3 1.1目的. . . . . . . . . . . . . . . . . . . . 5 1.2哲学. . . . . . . . . . . . . . . . . . . . 6 2。 インターネットNo.. . . . . . . . . . . . . . . . . . 6 2.1Is64Bits Enough? . . . . . . . . . . . . . . . . 6 2.2 なぜバージョン7? . . . . . . . . . . . . . . . . . . 7 2.3 バージョン7IPはバージョン4No.. . . . . . . . . . . 8 3の.72.4のAD番号. . . . . . . . . . . . . . . . . . . . 8 2.5Mappingを記述します。 IP: インターネットデータグラムプロトコル.93.1IPデータグラムヘッダー形式.103.1.1バージョン. . . . . . . . . . . . . . . . . . . . 10 3.1.2Headerの長さ、.103.1、.3Time、生体の.103.1.4Totalデータグラムの長さ. . . . . . . . . . . . . 11 3; 1.5 前進のルート識別子.113.1.6Destination. . . . . . . . . . . . . . . . . . 11 3.1.7Source. . . . . . . . . . . . . . . . . . . . 11 3.1.8プロトコル. . . . . . . . . . . . . . . . . . . 11 3.1.9Checksum. . . . . . . . . . . . . . . . . . . 11 3.1.10のオプション. . . . . . . . . . . . . . . . . . . . 11
Ullmann [Page 1] RFC 1475 TP/IX June 1993
ウルマン[1ページ]RFC1475TP/IX1993年6月
3.2 Option Format . . . . . . . . . . . . . . . . . . 12 3.2.1 Class (C) . . . . . . . . . . . . . . . . . . . 12 3.2.2 Copy on fragmentation (F) . . . . . . . . . . . 13 3.2.3 Type . . . . . . . . . . . . . . . . . . . . . 13 3.2.4 Length . . . . . . . . . . . . . . . . . . . . 13 3.2.5 Option data . . . . . . . . . . . . . . . . . . 13 3.3 IP options . . . . . . . . . . . . . . . . . . . 13 3.3.1 Null . . . . . . . . . . . . . . . . . . . . . 13 3.3.2 Fragment . . . . . . . . . . . . . . . . . . . 14 3.3.3 Last Fragment . . . . . . . . . . . . . . . . . 14 3.3.4 Don't Fragment . . . . . . . . . . . . . . . . 15 3.3.5 Don't Convert . . . . . . . . . . . . . . . . . 15 3.4 Forward route identifier . . . . . . . . . . . . 15 3.4.1 Procedure description . . . . . . . . . . . . . 15 3.4.2 Flows . . . . . . . . . . . . . . . . . . . . . 17 3.4.3 Mobile hosts . . . . . . . . . . . . . . . . . 17 4. TCP: Transport protocol . . . . . . . . . . . . . 18 4.1 TCP segment header format . . . . . . . . . . . . 18 4.1.1 Data offset . . . . . . . . . . . . . . . . . . 19 4.1.2 MBZ . . . . . . . . . . . . . . . . . . . . . . 19 4.1.3 Flags . . . . . . . . . . . . . . . . . . . . . 19 4.1.4 Checksum . . . . . . . . . . . . . . . . . . . 19 4.1.5 Source port . . . . . . . . . . . . . . . . . . 20 4.1.6 Destination port . . . . . . . . . . . . . . . 20 4.1.7 Sequence . . . . . . . . . . . . . . . . . . . 20 4.1.8 Acknowledgement . . . . . . . . . . . . . . . . 20 4.1.9 Window . . . . . . . . . . . . . . . . . . . . 20 4.1.10 Options . . . . . . . . . . . . . . . . . . . . 20 4.2 Port numbers . . . . . . . . . . . . . . . . . . 20 4.3 TCP options . . . . . . . . . . . . . . . . . . . 21 4.3.1 Option Format . . . . . . . . . . . . . . . . . 21 4.3.2 Null . . . . . . . . . . . . . . . . . . . . . 21 4.3.3 Maximum Segment Size . . . . . . . . . . . . . 21 4.3.4 Urgent Pointer . . . . . . . . . . . . . . . . 21 4.3.5 32 Bit rollover . . . . . . . . . . . . . . . . 21 5. UDP: User Datagram protocol . . . . . . . . . . . 22 5.1 UDP header format . . . . . . . . . . . . . . . . 22 5.1.1 Data offset . . . . . . . . . . . . . . . . . . 22 5.1.2 MBZ . . . . . . . . . . . . . . . . . . . . . . 22 5.1.3 Checksum . . . . . . . . . . . . . . . . . . . 22 5.1.4 Source port . . . . . . . . . . . . . . . . . . 22 5.1.5 Destination port . . . . . . . . . . . . . . . 22 5.1.6 Options . . . . . . . . . . . . . . . . . . . . 23 6. ICMP . . . . . . . . . . . . . . . . . . . . . . . 23 6.1 ICMP header format . . . . . . . . . . . . . . . 23 6.2 Conversion failed ICMP message . . . . . . . . . 23 7. Notes on the domain system . . . . . . . . . . . . 25 7.1 A records . . . . . . . . . . . . . . . . . . . . 25
3.2 (F). . . . . . . . . . . 13 3.2.3Type. . . . . . . . . . . . . . . . . . . . . 13 3.2.4Length. . . . . . . . . . . . . . . . . . . . 13 3.2.5の断片化Optionデータ. . . . . . . . . . . . . . . . . . 13 3.3IPオプション. . . . . . . . . . . . . . . . . . . 13 3.3.1Null. . . . . . . . . . . . . . . . . . . . . 13 3の上のオプションFormat. . . . . . . . . . . . . . . . . . 12 3.2.1Class(C). . . . . . . . . . . . . . . . . . . 12 3.2.2Copy; Convert.153.4ではなくFragment. . . . . . . . . . . . . . . . 15 3.3.5ドンではなく、.143.3.3Last Fragment. . . . . . . . . . . . . . . . . 14 3.3.4ドンを断片化してください。3.2 Forwardは識別子.153.4.1Procedure記述. . . . . . . . . . . . . 15 3.4.2Flows. . . . . . . . . . . . . . . . . . . . . 17 3.4.3人のモバイルホスト. . . . . . . . . . . . . . . . . 17 4を発送します。 TCP: トランスポート・プロトコル. . . . . . . . . . . . . 18 4.1TCPセグメントヘッダー形式. . . . . . . . . . . . 18 4.1.1Dataは.194.1.2MBZ. . . . . . . . . . . . . . . . . . . . . . 19 4.1.3Flags. . . . . . . . . . . . . . . . . . . . . 19 4.1.4Checksum. . . . . . . . . . . . . . . . . . . 19 4.1.5Sourceポート.204.1.6Destinationポート.204.1.7Sequence. . . . . . . . . . . . . . . . . . . 20 4.1を相殺します; 8 承認. . . . . . . . . . . . . . . . 20 4.1.9Window. . . . . . . . . . . . . . . . . . . . 20 4.1.10のオプション. . . . . . . . . . . . . . . . . . . . 20 4.2のPort No.. . . . . . . . . . . . . . . . . . 20 4.3TCPオプション…; . . . . . . . . 21 4.3.1 緊急のオプション形式. . . . . . . . . . . . . . . . . 21 4.3.2ヌル. . . . . . . . . . . . . . . . . . . . . 21 4.3.3の最大のセグメントサイズ. . . . . . . . . . . . . 21 4.3.4ポインタ. . . . . . . . . . . . . . . . 21 4.3.5 32ビットrollover. . . . . . . . . . . . . . . . 21 5。 UDP: ユーザデータグラムプロトコル.225.1UDPヘッダー形式. . . . . . . . . . . . . . . . 22 5.1.1Dataは.225.1.2MBZ. . . . . . . . . . . . . . . . . . . . . . 22 5.1.3Checksum. . . . . . . . . . . . . . . . . . . 22 5.1.4Sourceポート.225.1.5Destinationポート. . . . . . . . . . . . . . . 22 5.1.6Options. . . . . . . . . . . . . . . . . . . . 23 6を相殺します。 ICMP. . . . . . . . . . . . . . . . . . . . . . . 23 6.1ICMPヘッダー形式. . . . . . . . . . . . . . . 23 6.2ConversionはICMPメッセージ. . . . . . . . . 23 7に失敗しました。 .257.1のドメインシステムA記録. . . . . . . . . . . . . . . . . . . . 25に関する注
Ullmann [Page 2] RFC 1475 TP/IX June 1993
ウルマン[2ページ]RFC1475TP/IX1993年6月
7.2 PTR zone . . . . . . . . . . . . . . . . . . . . 25 8. Conversion between version 4 and version 7 . . . . 25 8.1 Version 4 IP address extension option . . . . . . 26 8.1.1 Option format . . . . . . . . . . . . . . . . . . 26 8.2 Fragmented datagrams . . . . . . . . . . . . . . . 26 8.3 Where does the conversion happen? . . . . . . . . 27 8.4 Hybrid IPv4 systems . . . . . . . . . . . . . . . 28 8.5 Maximum segment size in TCP . . . . . . . . . . . 28 8.6 Forwarding and redirects . . . . . . . . . . . . . 28 8.7 Design considerations . . . . . . . . . . . . . . 28 8.8 Conversion from IPv4 to IPv7 . . . . . . . . . . . 29 8.9 Conversion from IPv7 to IPv4 . . . . . . . . . . . 30 8.10 Conversion from TCPv4 to TCPv7 . . . . . . . . . . 31 8.11 Conversion from TCPv7 to TCPv4 . . . . . . . . . . 32 8.12 ICMP conversion . . . . . . . . . . . . . . . . . 33 9. Postscript . . . . . . . . . . . . . . . . . . . . 33 10. References . . . . . . . . . . . . . . . . . . . . 34 11. Security Considerations . . . . . . . . . . . . . 35 12. Author's Address . . . . . . . . . . . . . . . . . 35
7.2 PTRゾーン. . . . . . . . . . . . . . . . . . . . 25 8。 .268.3Whereが変換をするバージョン4とバージョン7.258.1バージョン4IPアドレス拡大オプション.268.1.1Option形式. . . . . . . . . . . . . . . . . . 26 8.2Fragmentedデータグラムの間の変換は起こりますか? . . . . . . . . 8.4台のハイブリッドIPv4システム. . . . . . . . . . . . . . . 28 8.5MaximumはTCP.288.6Forwardingでサイズを区分して、.288.7のDesign問題を向け直します。27、IPv4からIPv7までの.288.8Conversion; .298.9 IPv7からのIPv4.30 8.10TCPv7からTCPv4. . . . . . . . . . 32 8.12ICMP変換. . . . . . . . . . . . . . . . . 33 9へのTCPv4からTCPv7.31 8.11ConversionまでのConversionへの変換。 追伸. . . . . . . . . . . . . . . . . . . . 33 10。 参照. . . . . . . . . . . . . . . . . . . . 34 11。 セキュリティ問題. . . . . . . . . . . . . 35 12。 作者のアドレス. . . . . . . . . . . . . . . . . 35
1. Introduction
1. 序論
This memo presents the specification for version 7 of the Internet Protocol, as well as version 7 of the TCP and the user datagram protocol. Version 7 has been designed to address several major problems that have arisen as version 4 has evolved and been deployed, and to make a major step forward in the datagram switching and forwarding architecture of the Internet.
このメモはインターネットプロトコルのバージョン7のための仕様を提示します、TCPのバージョン7とユーザデータグラムプロトコルと同様に。 バージョン7は、バージョン4が発展されて、配備されたとき起こったいくつかの大した問題を記述して、データグラムの切り換えと推進における主要な前進をインターネットの構造にするように設計されています。
The major problems are threefold. First, the address space of version 4 is now seen to be too small. While it was viewed as being almost impossibly large when version 4 was designed, two things have occurred to create a problem. The first is a success crisis: the internet protocols have been more widely used and accepted than their designers anticipated. Also, technology has moved forward, putting microprocessors into devices not anticipated except as future dreams a decade ago.
大した問題は三倍です。 まず最初に、バージョン4のアドレス空間は今、小さ過ぎるのを見られます。 それがバージョン4が設計されたときほとんど信じられないほど大きいとして見なされていた間、2つのものが、問題を生じさせるために現れています。 1番目は成功危機です: インターネットプロトコルは、彼らのデザイナーが予期したより広く使用されていて受け入れられています。 また、将来の夢以外に、10年前に予期されなかった装置にマイクロプロセッサを入れて、技術は前方へ動きました。
The second major problem is a perceived routing explosion. The present routing architecture of the internet calls for routing each organization's network independently. It is becoming increasingly clear that this does not scale to a universal internet. While it is possible to route several billion networks in a flat, structureless domain, it is not desireable.
2番目の大した問題は知覚されたルーティング爆発です。 インターネットの現在のルーティング構造は、独自に各組織のネットワークを発送するように求めます。 これが普遍的なインターネットに比例しないのはますます明確になっています。 平坦なstructurelessドメインで数10億のネットワークを発送するのが可能ですが、それは「望-可能」ではありません。
There is also the political administrative issue of assigning network numbers to organizations. The version 4 administrative system calls for organizations to request network assignments from a single
また、ネットワークに数を配属する組織への政治上の管理問題があります。 組織が要求するバージョン4の管理システムコールはシングルから課題をネットワークでつなぎます。
Ullmann [Page 3] RFC 1475 TP/IX June 1993
ウルマン[3ページ]RFC1475TP/IX1993年6月
authority. While to some extent this has been alleviated by reserving blocks to delegated assignments, the address space is not large enough to do this in the necessary general case, with large blocks allocated to (e.g.) national authority.
権威。 ある程度これは代表として派遣された課題へのブロックを予約することによって、軽減されましたが、アドレス空間は必要な一般的な場合でこれができるくらいには大きくはありません、(例えば、)大量株を国内当局に割り当てていて。
The third problem is the increasing bandwidth of the networks and of the applications possible on the network. The TCP, while having proven useful on an unprecedented range of network speeds, is now the limiting factor at the highest speeds, due to restrictions of window size, sequence-space, and port numbers. These limitations can all be addressed by increasing the sizes of the relevant fields. See [RFC1323].
3番目の問題はネットワークとネットワークで可能なアプリケーションの増加する帯域幅です。 現在空前の範囲のネットワーク速度で有用であることが分かっている間、TCPは最も高い速度が限定因子です、ウィンドウサイズの制限、系列スペース、およびポートナンバーのため。 関連分野のサイズを増加させることによって、これらの制限をすべて記述できます。 [RFC1323]を見てください。
There is also an opportunity to move the technology forward, and take advantage of a combination of the best features of the hop-by-hop connectionless forwarding of version 4 (and CLNP) as well as the pre-established paths of version 5 (and, e.g., the OSI CONS).
そして、技術を前方へ動かせて、ホップごとのバージョン5のプレ確立した経路と同様にバージョン4(そして、CLNP)のコネクションレスな推進の最も良い特徴の組み合わせを利用する機会もある、(例えば、オウシ・コンズ)
Internet Version 7 includes four major areas of improvement, while at the same time retaining interoperation with version 4 with a small amount of conversion knowledge imposed on version 7 hosts and routers.
インターネットバージョン7は同時にバージョン7ホストとルータに課される少量の変換知識と共にバージョン4があるinteroperationを保有している間、改良の4つの主要な領域を含んでいます。
o It increases the address fields to 64 bits, with sufficient
space for visible future expansion of the internet.
o 十分なスペースに従って、それはインターネットの目に見える今後の拡大のためにアドレス・フィールドを64ビットまで増加させます。
o It adds a numbering layer for administrations, above the
organization or network layer, as well as providing more
space for subnetting within organizations.
o それは政権のために組織の中で、より多くのスペースをサブネッティングに提供することと同様に組織かネットワーク層を超えて付番層を加えます。
o It increases the range of speeds and network path delays over
which the TCP will operate satisfactorily, as well as the
number of transactions in bounded time that can be served by
a host.
o それは速度とTCPが満足に作動するネットワーク経路遅れの範囲を増加させます、ホストが勤めることができる境界がある時間で取引の数と同様に。
o Finally, it provides a forward route identifier in each
datagram, to support extremely fast path, circuit, or
flow-based forwarding, or any desired combination, while
preserving hop-by-hop connectivity.
o 最終的に、それは、非常に速く経路、サーキット、流れベースの推進、またはどんな必要な組み合わせもサポートするためにホップごとの接続性を保存している間、前進のルート識別子を各データグラムに供給します。
The result is not just a movement sideways, deploying a new network layer protocol to patch current problems. It is a significant step forward for network layer technology,
結果は横向きで動きであるだけではありません、現在の問題を修理するために新しいネットワーク層プロトコルを配備して。それはネットワーク層技術のための重要な前進です。
Ullmann [Page 4] RFC 1475 TP/IX June 1993
ウルマン[4ページ]RFC1475TP/IX1993年6月
1.1 Objectives
1.1 目的
The following are some of the objectives of the design.
↓これはデザインの目的のいくつかです。
o Use what has been learned from the IP version 4 protocol, fixing
things that are troublesome, and not fixing that which is not
broken.
o IPバージョン4プロトコルから学習されたことを使用してください、厄介なものを修理して、壊れていないそれは修理しないで。
o Retain the essential "look and feel" of the Internet protocol
suite. It has been very successful, and one doesn't argue with
success.
o インターネット・プロトコル群の不可欠の「ルック・アンド・フィール」を保有してください。 それは非常にうまくいっています、そして、人は成功で論争しません。
o Not introduce concepts that the Internet has shown do not belong
in the protocol definition. Best example: we do not want to add
any kind of routing information into the addressing, other than
the administrative hierarchy that has sometimes proved useful.
Note that the one feature in version 4 addressing (the class
system) designed to aid routing is now the most serious single
problem.
o インターネットが、プロトコル定義にはないように示したという概念を紹介してください。 最も良い例: どんな種類のルーティング情報もアドレシングに追加したいと思いません、時々有用であることが分かった管理階層構造を除いて。 ルーティングを支援するように設計された(クラスシステム)を記述するバージョン4における1つの特徴が現在最も重大なただ一つの問題であることに注意してください。
o Allow current hosts to interoperate, if not universally, at least
within an organization or larger area for the indefinite future.
There will be version 4 hosts for 10-15 years into the future,
the Internet must remain on good terms with them.
o そうでなければ、無期未来に少なくとも組織か、より広大な地域の中に現在のホストを一般に共同利用させてください。 未来までバージョン4ホストが10-15年間いて、インターネットは彼らで仲の良い間柄で残らなければなりません。
o Likewise, we must not impose the new version, telling sites they
must convert to stay connected. People resist imposed solutions.
It must not be marketed as something different from IPv4; the
differences must be down-played at every opportunity.
o 同様に、接続されていたままであるために変換しなければならないとサイトに言って、私たちは新しいバージョンを課してはいけません。 人々は課された解決策に抵抗します。 IPv4と何か異なったものとしてそれを売り出してはいけません。 あらゆる機会で違いを控え目に扱わなければなりません。
o The design must allow individual hosts and routers to be upgraded
effectively at random, with no transition plan constraints.
o デザインで、個々のホストとルータは変遷プラン規制なしで有効に無作為にアップグレードしなければなりません。
o The design must not require renumbering the Internet. The
administrative work already accomplished is immense, if it is to
be done again it will be in assigning NSAPs.
o デザインは、インターネットに番号を付け替えさせるのを必要としてはいけません。 既に実行された管理的な仕事が莫大である、再び完了しているつもりであると、NSAPsを割り当てるのにおいてそれがあるでしょう。
o It must allow IPv4 hosts to interoperate without any reduction in
function, without any modification to their software or
configuration. (Universal connectivity will be lost by IPv4
hosts, but they must be able to continue operating within their
organization at least.)
o それで、IPv4ホストは機能のどんな減少、彼らのソフトウェアか構成への少しも変更なしでも共同利用できなければなりません。 (普遍的な接続性はIPv4ホストによって失われるでしょうが、彼らは、少なくとも彼らの組織の中で作動し続けることができなければなりません。)
o It must permit network layer state-free translation of datagrams
between IPv4 and IPv7; this is important to the previous point,
and essential to early testing and transitional deployment.
o それはIPv4とIPv7の間のデータグラムに関するネットワーク層無州の翻訳を可能にしなければなりません。 これは、前のポイントに重要であって、早いテストと過渡的な展開に不可欠です。
o It must be a competent alternative to CLNP.
o それはCLNPへの十分な代替手段であるに違いありません。
Ullmann [Page 5] RFC 1475 TP/IX June 1993
ウルマン[5ページ]RFC1475TP/IX1993年6月
o It must not involve changing the semantics of the network layer
service in any way that invalidates the huge amount of work that
has gone into understanding how TCP (for example) functions in
the net, and the implementation of that understanding.
o それは、(例えば、)TCPがネット、およびその実現でどう機能するかが分かるのを理解するために入った巨大な仕事量を無効にするどんな方法でもネットワーク層サービスの意味論を変えることを伴ってはいけません。
o It must be defined Real Soon; the window of opportunity is almost
closed. It will take vendors 3 years to deploy from the time the
standard is rock-solid concrete.
o それは定義されたレアルSoonであるに違いありません。 機会の窓はほとんど閉じられます。 規格がしっかりしているコンクリートである時から展開するには業者に3年かかるでしょう。
I believe all of these are accomplishable in a consistent, well- engineered solution, and all are essential to the survival of the Internet.
私は、これらのすべてが一貫して、よく設計された解決策で達成可能であると信じています、そして、すべてがインターネットの生存に不可欠です。
1.2 Philosophy
1.2 哲学
Protocols should become simpler as they evolve.
発展するのに従って、プロトコルは、より簡単になるべきです。
2. Internet numbers
2. インターネット番号
The version 4 numbering system has proven to be very flexible, (mostly) expandable, and simple. In short: it works. There are two problems, neither serious when this specification was first developed in 1988 and 1989, but have as expected become more serious:
バージョン4付番システムは非常にフレキシブルで、(ほとんど)拡張可能で、簡単であると判明しました。 要するに: それは働いています。 予想されるとして1989であった以外に、この仕様であるなら重大であるのは、どちらも、2つの問題があって、1988年に開発された1番目と1989ではありませんでした。より重大になってください:
o The division into network, and then subnet, is insufficient.
Almost all sites need a network assignment large enough to
subnet. At the top of the hierarchy, there is a need to
assign administrative domains.
o ネットワーク、および次に、サブネットへの分割は不十分です。 ほとんどすべてのサイトがサブネットに十分大きいネットワーク課題を必要とします。 階層構造の最上部に、管理ドメインを割り当てる必要があります。
o As bit-packing is done to accomplish the desired network
structure, the 32 bit limit causes more and more aggravation.
o 必要なネットワーク構造を達成するためにビットパッキングをするように、32ビットの限界はますます多くの深刻化を引き起こします。
2.1 Is 64 Bits Enough?
2.1 64ビットは十分ですか?
Consider: (thought experiment) 32 bits presently numbers "all" of the computers in the world, and another 32 bits could be used to number all of the bytes of on-line storage on each computer. (Most have a lot less than 4 gigabytes on-line, the ones that have more could be notionally assigned more than one address.)
考えます: (思考実験) 32ビットは現在世界でコンピュータの「すべて」に付番します、そして、各コンピュータで優にオンラインストレージのバイトに付番するのにもう32ビットは使用できました。 (大部分には、はるかに4つ未満のギガバイトがオンラインであって、概念的に以上を持っているものに1つ以上のアドレスは割り当てることができました。)
So: 64 bits is enough to number every byte of online storage in existence today, in a hierarchical structured numbering plan.
そのように: 64ビットは今日、数へのバイト毎に階層的な構造化された付番プランに現存するオンラインストレージに十分です。
Another way of looking at 64 bits: it is more than 2 billion addresses for each person on the planet. Even if I have microprocessors in my shirt buttons I'm not going to have that many. 32 bits, on the other hand, was never going to be sufficient: there are more than 2^32 people.
64ビットを見る別の方法: 惑星の各人あたりそれは20億以上のアドレスです。 シャツボタンにマイクロプロセッサを持っても、私はそれを多くにするつもりではありません。 他方では、32ビットは決して十分ではありませんでした: 2以上^32の人々がいます。
Ullmann [Page 6] RFC 1475 TP/IX June 1993
ウルマン[6ページ]RFC1475TP/IX1993年6月
2.2 Why version 7?
2.2 なぜバージョン7?
It was clearly recognized at the start of this project in 1988 that making the address 64 bits implies a new IP header format, which was called either "TP/IX" or "IP version 7"; there wasn't anything magic about the number 7, I made it up. Version 4 is the familiar current version of IP. Version 5 is the experimental ST (Stream) protocol. ST-II, a newer version of ST, uses the same version number, something I was not aware of until recently; I suspected it might have been allocated 6. Besides, I liked 7.
または、1988年のこのプロジェクトの始めにアドレスを64ビット作ると「TP/IX」と呼ばれた新しいIPヘッダー形式が含意されると明確に認められた、「IP、バージョン7インチ」、。 No.7に関して魔法であるものは何もなくて、私はそれを作りました。 バージョン4はIPの身近な最新版です。 バージョン5は実験ST(ストリーム)プロトコルです。 ST-II(STの、より新しいバージョン)は同じバージョン番号、最近まで私が意識していなかった何かを使用します。 私は、それが6に割り当てられたかもしれないと疑いました。 そのうえ、私は7が好きでした。
Apparently (as reported by Bob Braden) the IAB followed much the same logic, and may have had the idea planted by the mention of version 7 in the "Toasternet Part II" memo. The IAB in June 1992 floated a proposal that CLNP, or a CLNP-based design, be Internet Version 7. (And promptly got themselves toasted.) However, close inspection of the bits shows that CLNP is clearly version 8.
明らか(ボブ・ブレーデンによって報告されるように)に、IABは似たり寄ったりの論理に従って、「ToasternetパートII」というメモにおける、バージョン7の言及で考えを植えさせたかもしれません。 IAB、1992年6月の浮かべられたa提案におけるそのCLNP、またはCLNPベースのデザイン、インターネットバージョン7になってください。 (そして、即座に、自分たちを乾杯させます。) しかしながら、ビットの厳重な検査は、CLNPが明確にバージョン8であることを示します。
2.3 The version 7 IP address
2.3 バージョン7IPアドレス
The Version 7 IP 64 bit address looks like:
バージョン7IP64ビット・アドレスに似ています:
+-------+-------+-------+-------+-------+-------+-------+-------+
| Admin Domain | Network | Host |
+-------+-------+-------+-------+-------+-------+-------+-------+
+-------+-------+-------+-------+-------+-------+-------+-------+ | アドミンドメイン| ネットワーク| ホスト| +-------+-------+-------+-------+-------+-------+-------+-------+
Note: the boundary between "network" and "host" is no more fixed than it is today; each (sub)network will have its own mask. Just as the mask today can be anywhere from FF00 0000 (8/24) to FFFF FFFC (30/2), the mask for the 64 bit address can reasonably be FFFF FF00 0000 0000 (24/40) to FFFF FFFF FFFF FFFC (62/2).
以下に注意してください。 「ネットワーク」と「ホスト」の間の境界は今日のそれほど固定されていません。 それぞれの(潜水艦)ネットワークには、それ自身のマスクがあるでしょう。 ちょうど今日のマスクがどこでもFF00 0000(8/24)からFFFF FFFC(30/2)まであることができるので、64ビット・アドレスのためのマスクは合理的にFFFF FFFF FFFF FFFC(62/2)へのFFFF FF00 0000 0000(24/40)であるかもしれない。
The AD (Administrative Domain), identifies an administration which may be a service provider, a national administration, or a large multi-organization (e.g. a government). The idea is that there should not be more than a few hundred of these at first, and eventually thousands or tens of thousands at most. (But note that we do not introduce a hard limit of 2^16 here; this estimate may be off by a few orders of magnitude.) Since only 1/4th of the address space is initially used (first two bits are 01), the remainder can then be allocated in the future with more information available.
AD(管理Domain)、サービスプロバイダー、国家の管理、または大きいマルチ組織であるかもしれない(例えば、政府)管理を特定します。 考えはこれらのかなり多くの100が最初に、そして、結局数千か高々何万にあるべきでないということです。 (しかし、私たちがここで2^16の困難な限界を導入しないことに注意してください; この見積りは数桁割引しているかもしれません。) アドレス空間の1/4番目だけが初めは使用されるので(最初の2ビットは01です)、そして、詳しい情報が利用可能な状態で将来、残りを割り当てることができます。
Most individual organizations would not be ADs. In the short term, ADs are known to the "core routing"; it pays to keep the number smallish, a few thousand given current routing technology. In the long term, this is not necessary. Big administrations (i.e., with tens of millions of networks) get small blocks where needed, or additional single AD numbers when needed.
ほとんどの個々の組織はADsでないでしょう。 短期で、ADsは「コアルーティング」に知られています。 数1,000の与えられた電流が技術を発送して、数を小さめに保つのは得になります。 長期で、これは必要ではありません。 必要であると、大きい政権(すなわち、何千万ものネットワークがある)は必要であるどこ、または追加ただ一つのAD番号をわずかなブロックに届けるか。
Ullmann [Page 7] RFC 1475 TP/IX June 1993
ウルマン[7ページ]RFC1475TP/IX1993年6月
While the AD may be used for last resort routing (with a 24/40 mask), it is primarily only an administrative device. Most routing will be done on the entire 48 bit AD+network number, or sub and super-sets of those numbers. (I.e., masks between about 32/32 and 56/8.)
ADは切り札のルーティング(24/40マスクがある)に使用されるかもしれませんが、それは主として管理デバイスにすぎません。 48ビットの全体の西暦+ネットワーク・ナンバーか、潜水艦とスーパーセットでそれらの数についてほとんどのルーティングをするでしょう。 (すなわち、およそ32/32〜56/8にマスクをかけます。)
Some ADs (e.g., NSF) may make permanent assignments; others (such as a telephone company defining a network number for each subscriber line) may tie the assignment to such a subscription. But in no case does this require traffic to be routed via the AD.
いくつかのADs(例えば、NSF)が永久的な課題をするかもしれません。 他のもの(それぞれの加入者系列のネットワーク・ナンバーを定義する電話会社などの)はそのような購読に課題を結ぶかもしれません。 しかし、これは、トラフィックがADを通して発送されるのを決して、必要としません。
2.4 AD numbers
2.4 AD番号
AD numbers are allocated out of the same numbering space as network numbers. This means that a version 4 address can be distinguished from the first 32 bits of a version 7 address. This is useful to help prevent the inadvertent use of the first half of the longer address by a version 4 host.
ネットワーク・ナンバーと同じ付番スペースからAD番号を割り当てます。 これは、バージョン7アドレスの最初の32ビットとバージョン4アドレスを区別できることを意味します。 これは、バージョン4ホストによる、より長いアドレスの前半の不注意な使用を防ぐのを助けるために役に立ちます。
There is a non-trivial amount of software that assumes that an "int" is the same size and shape as an IP address, and does things like "ipaddr = *(int *)ptr". This usage has always been incorrect, but does occur with disturbing frequency. As IPv7 8 byte addresses appear in the application layers, this software will find those addresses unreachable; this is preferable to interacting with a random host.
"int"がIPアドレスと同じ大きさ形状であると仮定して、「ipaddrは*(int*)ptrと等しいです」のようにことをする重要な量のソフトウェアがあります。 この用法は、いつも不正確でしたが、不穏な頻度で起こります。 IPv7 8バイト・アドレスが応用層に現れるように、このソフトウェアは、それらのアドレスが手が届かないのがわかるでしょう。 これは無作為のホストと対話するより望ましいです。
One possible method would be to allocate ADs in the range 96.0.0 to 192.255.255, using the top 1/4 of the version 4 class A space. It is probably best to allocate the first component downwards from 192, so that the boundary between class A and AD can be moved if desired later. This initial allocation provides for 2031616 ADs, many more than there should be even in full deployment.
192.255に、1/4のトップバージョン4を.255、使用するのは属します。1つの可能なメソッドが範囲にADsを割り当てるだろうことである、96.0、.0、Aスペース。 192から最初のコンポーネントを下向きに割り当てるのはたぶん最も十分です、後で望まれているならクラスAとADの間の境界を動かすことができるように。 この初期の配分は完全な展開でさえあるべきであるよりずっと多く2031616ADsに備えます。
Eventually, both AD and network will use the full 24 bit space available to them. Knowledge of the AD range should not be coded into software. If it was coded in, that software would break when the entire 24 bit space is used for ADs. (This lesson should have been learned from CIDR.)
結局、ADとネットワークの両方がそれらに、利用可能な24ビットの完全なスペースを使用するでしょう。 AD範囲に関する知識をソフトウェアにコード化するべきではありません。 24ビットの全体のスペースがADsに使用されるとき、それが中でコード化されるなら、そのソフトウェアが知れ渡るでしょうに。 (このレッスンはCIDRから学習されるべきでした。)
2.5 Mapping of version 4 numbers
2.5 バージョン4番号に関するマッピング
Initially, all existing Internet numbers are defined as belonging to the NSF/Internet AD, number 192.0.0.
初めはすべての既存のインターネット番号がNSF/インターネットADに属する数と定義される、192.0、.0
Ullmann [Page 8] RFC 1475 TP/IX June 1993
ウルマン[8ページ]RFC1475TP/IX1993年6月
The mapping from/to version 4 IP addresses:
/からバージョン4IPアドレスまでのマッピング:
+-------+-------+-------+-------+-------+-------+-------+-------+
| Admin Domain | Network | Host |
+-------+-------+-------+-------+-------+-------+-------+-------+
[ fixed at A0 00 00 ] [ 1st 24 bits of V4 IP] [1] [last 8]
+-------+-------+-------+-------+-------+-------+-------+-------+ | アドミンドメイン| ネットワーク| ホスト| +-------+-------+-------+-------+-------+-------+-------+-------+ [A0 00 00に修理されています][V4 IPの最初の24ビット][1][ベスト8]
So, for example, 192.42.95.15 (V4) becomes 192.0.0.192.42.95.1.15.
.15(V4)は192.0になります。そのようにと、例えば、192.42、.95、.0 .192 .42 .95 .1 .15。
And the "standard" loopback interface address becomes 192.0.0.127.0.0.1.1 (I can see explaining that in 2015 to someone born in 1995.)
そして、「標準」のループバックインターフェース・アドレスが192.0になる、.0、.127、.0、.0、.1、.1(私は2015年に1995年にだれか生まれる人にそれについて説明しながら、見ることができます。)
The present protocol multicast (192.0.0.224.x.y.1.z) and loopback addresses are permanently allocated in the NSF AD.
永久に、NSF ADに現在のプロトコルマルチキャスト(192.0.0.224.x. y.1.z)とループバックアドレスを割り当てます。
3. IP: Internet datagram protocol
3. IP: インターネットデータグラムプロトコル
The Internet datagram protocol is revised to expand some fields (most notably the addresses), while removing and relegating to options all fields not universally useful (imperative) in every datagram in every environment.
インターネットデータグラムプロトコルはいくつかの分野(最も著しくアドレス)を広げるために取り外している間、改訂されます、そして、すべてをオプションに左遷すると、一般に役に立つ(命令)でないのはあらゆるデータグラムであらゆる環境でさばかれます。
This results in some simplification, a length less than twice the size of IPv4 even though most fields are doubled in size, and an expanded space for options.
ほとんどの分野がオプションのためにサイズ、および拡張スペースで倍にされますが、これは何らかの簡素化、IPv4のサイズの2倍より少ない長さをもたらします。
There is also a change in the option philosophy from IPv4: it specified that implementation of options was not optional, what was optional was the existence of options in any given datagram. This is changed in IPv7: no option need be implemented to be fully conformant. However, implementations must understand the option classes; and a future Host Requirements specification for hosts and routers used in the "connected Internet" may require some options in its profile, e.g., Fragment would probably be required.
また、オプション哲学における変化はIPv4から来ています: オプションの実装が任意でなかったのが指定して、任意であったことはどんな与えられたデータグラムのオプションの存在でした。 IPv7でこれを変えます: オプションは全く完全にconformantであると実装される必要はありません。 しかしながら、実装はオプションのクラスを理解しなければなりません。 そして、ホストとルータのための仕様が「接続インターネット」で使用したHost Requirementsがプロフィールのいくつかのオプションを必要とするかもしれない未来、例えばFragmentがたぶん必要でしょう。
Digression: In IPv4, options are often "considered harmful". It is the opinion of the present author that this is because they are rarely needed, and not designed to be processed rapidly on most architectures. This leads to little or no attempt to improve performance in implementations, while at the same time enormous effort is dedicated to optimization of the no-option case. IPv7 is expected to be different on both counts.
脱線: IPv4では、オプションはしばしば「有害であると考えられます」。 ほとんどのアーキテクチャで急速に処理されるのは、これがそれらがめったに必要でなく、また設計されていないからである現在の作者の意見です。 これはまず実装における性能を向上させる試みに通じません、莫大な取り組みが同時に、オプションがないケースの最適化に捧げられますが。 IPv7を両方のカウントのときに異ならせると予想されます。
Fields are always aligned on their own size; the 64 bit fields on 64 bit intervals from the start of the datagram.
分野はそれら自身のサイズでいつも並べられます。 64はデータグラムの始まりから64ビットの間隔の分野に噛み付きました。
Options are all 32 bit aligned, and the null option can be used to
オプションは32ビットが並べて、ヌルオプションが使用されている場合があるすべてです。
Ullmann [Page 9] RFC 1475 TP/IX June 1993
ウルマン[9ページ]RFC1475TP/IX1993年6月
push a subsequent option (or the transport layer header) into 64 bit or 64+32 off-phase alignment as desired.
その後のオプション(または、トランスポート層ヘッダー)を64ビットか64ビットに押してください。必要な+32オフフェーズ同じくらい整列。
3.1 IP datagram header format
3.1 IPデータグラムヘッダー形式
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|version| header length | time to live |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| total datagram length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ forward route identifier +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ destination address +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ source address +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| protocol | checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |バージョン| ヘッダ長| 生きる時間| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 総データグラムの長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + 前進のルート識別子+| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + 送付先アドレス+| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + ソースアドレス+| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | プロトコル| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | オプション| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A description of each field follows.
それぞれの分野の記述は続きます。
3.1.1 Version
3.1.1 バージョン
This document describes version 7 of the protocol.
このドキュメントはプロトコルのバージョン7について説明します。
3.1.2 Header length
3.1.2 ヘッダ長
The header length is a 12 bit count of the number of 32 bit words in the IPv7 header. This allows a header to be (theoretically at least) up to 16380 bytes in length.
ヘッダ長はIPv7ヘッダーの32ビットの単語の数の12ビットのカウントです。 これは、ヘッダーは長さが最大(理論的に少なくとも)16380バイトであることを許容します。
3.1.3 Time to live
3.1.3生きる時間
The time to live is a 16 bit count, nominally in 1/16 seconds. Each hop is required to decrement TTL by at least one.
生きるのが、16ビットである時に、1/16秒以降、名目上は数えてください。 各ホップが、TTLを少なくとも1つ減少させるのに必要です。
This definition should allow continuation of the useful (even though not entirely valid) interpretation of TTL as a hop count, while we
この定義はホップカウントとしてTTLの役に立つ(完全に有効ではありませんが)解釈の継続を許すべきです、私たちである間
Ullmann [Page 10] RFC 1475 TP/IX June 1993
ウルマン[10ページ]RFC1475TP/IX1993年6月
move to faster networks and routers. (The most familiar use is by "traceroute", which really ought to be directly implemented by one or more ICMP messages.)
より速いネットワークとルータに移行してください。 (最も身近な使用が本当に1つ以上のICMPメッセージによって直接実装されるべきである「トレースルート」であります。)
The scale factor converts the usual version 4 default TTL into a larger number of hops. This is desireable because the forward route architecture of version 7 enables the construction of simpler, faster switches, and this may cause the network diameter to increase.
位取り因数は普通のバージョン4デフォルトTTLをより多くのホップに変換します。 バージョン7の前進のルートアーキテクチャが、より簡単で、より速いスイッチの構造を可能にするので、これは「望-可能」です、そして、ネットワーク直径を増えさせるかもしれません。
3.1.4 Total datagram length
3.1.4 総データグラムの長さ
The 32 bit length of the entire datagram in octets. A datagram can therefore be up to 4294967295 bytes in overall length. Particular networks will normally impose lower limits.
32は八重奏における、全体のデータグラムの長さに噛み付きました。 したがって、データグラムは全長が最大4294967295バイトであるかもしれません。 通常、特定のネットワークは下限を課すでしょう。
3.1.5 Forward route identifier
3.1.5 前進のルート識別子
The identifier from the routing protocol to be used by the next hop router to find its next hop. (A more complete description is given below.)
次のホップルータによって使用された、次のホップを見つけるべきであるルーティング・プロトコルからの識別子。 (より完全な記述を以下に与えます。)
3.1.6 Destination
3.1.6 目的地
The 64 bit IPv7 destination address.
64はIPv7送付先アドレスに噛み付きました。
3.1.7 Source
3.1.7 ソース
The 64 bit IPv7 source address.
64はIPv7ソースアドレスに噛み付きました。
3.1.8 Protocol
3.1.8 プロトコル
The transport layer protocol, e.g., TCP is 6. The present code space for this layer of demultiplexing is about half full. Expanding it to 16 bits, allowing 65535 registered "transport" layers seems prudent.
トランスポート層プロトコルであり、例えば、TCPは6歳です。 この層の逆多重化のための現在のコードスペースは半分入るのに関するものです。 16ビットにそれを広げて、65535個の登録された「輸送」層を許容するのは慎重に思えます。
3.1.9 Checksum
3.1.9 チェックサム
The checksum is a 16 bit checksum of the entire IP header, using the familiar algorithm used in IPv4.
IPv4で使用される身近なアルゴリズムを使用して、チェックサムは全体のIPヘッダーの16ビットのチェックサムです。
3.1.10 Options
3.1.10 オプション
Options may follow. They are variable length, and always 32 bit aligned, as discussed previously.
オプションは続くかもしれません。 それらは可変長です、そして、いつも32ビットは以前に議論するように並びました。
Ullmann [Page 11] RFC 1475 TP/IX June 1993
ウルマン[11ページ]RFC1475TP/IX1993年6月
3.2 Option Format
3.2 オプション形式
Each option begins with a 32 bit header:
各オプションは32ビットのヘッダーと共に始まります:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| C |F| type | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option data ... | padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | C|F| タイプ| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | オプションデータ… | 詰め物| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A description of each field:
それぞれの分野の記述:
3.2.1 Class (C)
3.2.1 クラス(C)
This field tells implementations what to do with datagrams containing options they do not understand. No implementation is required to implement (i.e., understand) any given option by the TCP/IP specification itself.
この分野は、データグラムがそれらがするオプションを含んでいてするべきことが分からないと実装に言います。 TCP/IP仕様自体によるオプションを考えて、実装は、全くいずれも実装すること(すなわち、分かる)に必要ではありません。
Classes:
クラス:
0 use or forward and include this option unmodified
1 use this datagram, but do not forward the datagram
2 discard, or forward and include this option unmodified
3 discard this datagram
0 これが変更されていない1をゆだねる使用かフォワードとインクルードがこのデータグラムを使用します、2の破棄、またはフォワードをデータグラムに送って、このオプション変更されていない3が捨てるインクルードにこのデータグラムは送りませんが
A host receiving a datagram addressed to itself will use it if there are no unknown options of class 2 or 3. A router receiving a datagram not addressed to it will forward the datagram if and only if there are no unknown options of class 1 or 3. (The astute reader will note that the bits can also be seen as having individual interpretations, one allowing use even if unknown, one allowing forwarding if unknown.)
クラス2か3のどんな未知のオプションもないと、それ自体に扱われたデータグラムを受け取るホストはそれを使用するでしょう。 それに扱われなかったデータグラムを受けるルータがデータグラムを進める、単に、クラス1か3のどんな未知のオプションもありません。 (抜け目のない読者は、また、ビットは個々の解釈、1つが許容されて、未知であっても使用を許すものを持っていると進めますが、未知で考えられることができることに注意するでしょう。)
Note that classes 0 and 2 are imperative: if the datagram is forwarded, the unknown option must be included.
クラス0と2が必須であることに注意してください: データグラムを進めるなら、未知のオプションを含まなければなりません。
Class and type are entirely orthogonal, different implementations might use different classes for the same option, except where restricted by the option definition.
クラスとタイプが完全に直交している、異なった実装は同じオプションに異なったクラスを使用するかもしれません、オプション定義で制限されるのを除いて。
Also note that for options that are known (implemented by) the host or router, the class has no meaning; the option definition totally determines the behavior. (Although it should be noted that the option might explicitly define a class dependent behavior.)
また、知られている(実装されます)オプションによってそれに注意してください、ホストかルータ、クラスには、意味がありません。 オプション定義は振舞いを完全に決定します。 (オプションが明らかにクラスに依存する振舞いを定義するかもしれないことに注意されるべきですが。)
Ullmann [Page 12] RFC 1475 TP/IX June 1993
ウルマン[12ページ]RFC1475TP/IX1993年6月
3.2.2 Copy on fragmentation (F)
3.2.2 断片化でのコピー(F)
If the F bit is set, this option must be copied into all fragments when a datagram is fragmented. If the F bit is reset (zero), the option must only be copied into the first (zero-offset) fragment.
データグラムが断片化されるとき、Fビットが設定されるなら、すべての断片にこのオプションをコピーしなければなりません。 Fビットがリセット(ゼロ)であるなら、最初(ゼロオフセット)の断片にオプションをコピーするだけでよいです。
3.2.3 Type
3.2.3 タイプ
The type field identifies the particular option, types being registered as well known values in the internet. A few of the options with their types are described below.
タイプがインターネットで登録されたまた、知られている値でありタイプ分野は特定のオプションを特定します。 彼らのタイプとのオプションのいくつかは以下で説明されます。
3.2.4 Length
3.2.4 長さ
Length of the option data, in bytes.
バイトで表現されるオプションデータの長さ。
3.2.5 Option data
3.2.5 オプションデータ
Variable length specified by the length field, plus 0-3 bytes of zeros to pad to a 32 bit boundary. Fields within the option data that are 64 bits long are normally placed on the assumption that the option header is off-phase aligned, the usual case when the option is the only one present, and immediately follows the IP header.
長さの分野、および32ビット境界に水増しする0-3バイトのゼロに従って、可変長は指定しました。 通常、長さ64ビットであるオプションデータの中の野原はオプションヘッダーがオフフェーズが並びました、オプションが唯一無二のプレゼントであることの普通のケースということであり、すぐにIPヘッダーについて来るという前提に置かれます。
3.3 IP options
3.3 IPオプション
The following sections describe the options defined to emulate IPv4 features, or necessary in the basic structure of the protocol.
以下のセクションは特徴の、または、プロトコルの基本構造で必要なIPv4を見習うために定義されたオプションについて説明します。
3.3.1 Null
3.3.1 ヌル
The null option, type 0, provides for a space filler in the option area. The data may be of any size, including 0 bytes (perhaps the most useful case.)
0は、ヌルオプションがオプション部門に詰物に備えるのをタイプします。 データは0バイトを含むどんなサイズのものであるかもしれません。(恐らく最も役に立つケース。)
It may be used to change alignment of the following options or to replace an option being deleted, by setting type to 0 and class to 0, leaving the length and content of the data unmodified. (Note that this implies that options must not contain "secret" data, relying on class 3 to prevent the data from leaving the domain of routers that understand the option.)
それは以下のオプションの整列を変えるか、または削除されるオプションを置き換えるのに使用されるかもしれません、0へのタイプと0へのクラスを設定することによって、データの長さと内容を変更されていないままにして。 (これが、オプションが「秘密」のデータを含んではいけないのを含意することに注意してください、データがオプションを理解しているルータのドメインを出るのを防ぐためにクラス3を当てにして。)
Null is normally class 0, and need not be implemented to serve its function.
ヌルは、通常クラス0であり、機能を果たすために実行される必要はありません。
Ullmann [Page 13] RFC 1475 TP/IX June 1993
ウルマン[13ページ]RFC1475TP/IX1993年6月
3.3.2 Fragment
3.3.2 断片
Fragment (type 1) indicates that the datagram is part of a complete IP datagram. It is always class 2.
断片(1をタイプする)は、データグラムが完全なIPデータグラムの一部であることを示します。 いつもそれはクラス2です。
The data consists of (one of) the 64 bit IP address(es) of the router doing the fragmentation, a 64 bit datagram ID generated by that router, and a 32 bit fragment offset. The IDs should be generated so as to be very likely unique over a period of time larger than the TCP MSL (maximum segment lifetime). (The TCP ISN (initial sequence number) generator might be used to initialize the ID generator in a router.)
データが成る、(1つ、)、断片化をするルータの64ビットのIPアドレス(es)、IDがそのルータで発生させた64ビットのデータグラム、および32ビットの断片は相殺されます。 IDは、TCP MSL(最大のセグメント生涯)より大きい期間にわたってユニークな状態で非常にありそうになるように発生するべきです。 (TCP ISN(初期シーケンス番号)ジェネレータはルータでIDジェネレータを初期化するのに使用されるかもしれません。)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| C |F| type | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ fragmenting router IP address +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ datagram ID +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | C|F| タイプ| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + 断片化ルータIPアドレス+| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + データグラムID+| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 相殺されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
If a datagram must be refragmented, the original 128 bit address+ID is preserved, so that the datagram can be reassembled from any sufficient set of the resulting fragments. The 64 bits fields are positioned so that they are aligned in the usual case of the fragment option following the IP header.
データグラムを再断片化しなければならないなら、128ビットの元のアドレス+IDは保持されます、結果として起こる断片のどんな十分なセットからもデータグラムを組み立て直すことができるように。 64ビットの野原が置かれるので、IPヘッダーに続いて、それらは断片オプションの普通の場合で並べられます。
A router implementing Fragment (doing fragmentation) must recognize the Don't Fragment option.
Fragment(断片化する)を実行するルータはドンのためにどんなFragmentオプションも認識してはいけません。
3.3.3 Last Fragment
3.3.3 最後の断片
Last Fragment (type 2) has the same format as Fragment, but implies that this datagram is the last fragment needed to reassemble the original datagram.
最後に、Fragment(2をタイプする)は、Fragmentと同じ形式を持っていますが、このデータグラムがオリジナルのデータグラムを組み立て直すのが必要である最後の断片であることを含意します。
Note that an implementation can reasonably add arriving datagrams with Fragment to a cache, and then attempt a reassembly when a datagram with Last Fragment arrives (and the the total length is known); this will work well when datagrams are not reordered in the
実現がFragmentと共に到着データグラムをキャッシュに合理的に加えることができることに注意してください、そして、Last Fragmentがあるデータグラムが届いたら(全長は知られています)、次に、再アセンブリを試みてください。 データグラムで再命令されないと、これはうまくいくでしょう。
Ullmann [Page 14] RFC 1475 TP/IX June 1993
ウルマン[14ページ]RFC1475TP/IX1993年6月
network.
ネットワークでつなぎます。
3.3.4 Don't Fragment
3.3.4 断片化しないでください。
This option (type 3, class 0) indicates that the datagram may not be fragmented. If it can not be forwarded without fragmentation, it is discarded, and the appropriate ICMP message sent. (Unless, of course, the datagram is an ICMP message.) There is no data present.
このオプション(3、クラス0をタイプする)は、データグラムが断片化されないかもしれないのを示します。 断片化なしでそれを進めることができないなら、捨てられました、そして、適切なICMPメッセージは発信しました。 (データグラムがもちろんICMPメッセージでないなら。) どんな存在しているデータもありません。
3.3.5 Don't Convert
3.3.5 変換しないでください。
The Don't Convert option prohibits conversion from IPv7 to IPv4 protocol, requiring instead that the datagram be discarded and an ICMP message sent (conversion failed/don't convert set). It is type 4, usually class 0, and must be implemented by any router implementing conversion. A host is under no such constraint; like any protocol specification, only the "bits on the wire" can be specified, the host receiving the datagram may convert it as part of its procedure. There is no data present in this option.
どんなConvertもゆだねないドンがIPv7からIPv4プロトコルまでの変換、代わりにデータグラムが捨てられるのが必要であり、および送られたICMPメッセージを禁止する、(変換、失敗されて、/がセットを変換しない、) それをタイプ4、通常クラス0であり、変換を実行するどんなルータでも実行しなければなりません。 ホストはどんなそのような規制でもいません。 データグラムを受け取るホストは、どんなプロトコル仕様のようにも、「ワイヤのビット」しか指定できないで、手順の一部としてそれを変換するかもしれません。 このオプションにおける現在のどんなデータもありません。
3.4 Forward route identifier
3.4 前進のルート識別子
Each IP datagram carries a 64 bit field, called "forward route identifier", that is updated (if the information is available) at each hop. This field's value is derived from the routing protocol (e.g., RAP [RFC1476]). It is used to expedite routing decisions by preserving knowledge where possible between consecutive routers. It can also be used to make datagrams stay within reserved flows and mobile-host tunnels where required.
それぞれのIPデータグラムは各ホップでアップデートされる(情報が利用可能であるなら)「前進のルート識別子」と呼ばれる64ビットの野原を運びます。 これはルーティング・プロトコル(例えば、RAP[RFC1476])から得られますフィールドのものが、評価する。 それは、連続したルータの間で可能であるところに知識を保存することによってルーティング決定を速めるのに使用されます。 また、データグラムに必要であるところに予約された流れとモバイルホストトンネルの範囲内にとどまらせるのにそれを使用できます。
3.4.1 Procedure description
3.4.1 手順記述
Consider 3 routers, A, B, and C. Traffic is passing through them, between two other hosts (or networks), X and Y, packets are going XABCY and YCBAX. Consider only one direction: routing info flowing from C to A, to provide a route from A to C. The same thing will be happening in the other direction.
Y、パケットは、3つのルータを考えてください、A、B、C.Trafficはそれらを通り抜けています、他の2人のホスト(または、ネットワーク)の間で、X、行っているXABCYとYCBAXです。 一方向だけを考えてください: CからAまで流れるインフォメーションを発送して、AからC.までのルートに同じものを供給するのはもう片方の方向にナウくなるでしょう。
An explanation of the notation:
記法に関する説明:
R(r,d,i,h) A route that means: "from router r, to go toward
final destination d, replace the forward route
identifier in the packet with i, and take next
hop h."
R(r、d、i、h)は以下を意味するルートです。 「ルータrから、最終的な目的地dに向かって行くためにパケットで前進のルート識別子をiに取り替えてください、そして、次のホップh.を取ってください」
Ri(r,d) An opaque (outside of router r) identifier, that can
be used by r to find R(r,d,...).
Ri、(r、d) 不明瞭な(ルータrの外)識別子であり、それはrによって使用されて、Rが(r、d)であることがわかることができます。
Ullmann [Page 15] RFC 1475 TP/IX June 1993
ウルマン[15ページ]RFC1475TP/IX1993年6月
Flowi(r,rt) An opaque (outside of router r) identifier, that
router r can use to find a flow or tunnel with which
the datagram is associated, and from that the route
rt on which the flow or tunnel is built, as well as
the Flowi() for the subsequent hop.
Flowi(r、rt)は不明瞭な(ルータrの外)識別子(rが流れかトンネルがその後のホップのためのFlowi()と同様に建設されるルートrtを関連していて、それからデータグラム流れかトンネルに見つけるのに使用できるそのルータ)です。
Ri(Dgram) The forward route identifier in a datagram.
Ri、(Dgram) データグラムの前進のルート識別子。
Router C announces a route R(C,Y,0,Y) to router B. It includes in it an identifier Ri(C,Y) internal to C, that will allow C to find the route rapidly. (A table index, or an actual memory address.)
ルータCは、ルータB.ItへのルートR(C、Y、0、Y)がそれにCへの内部のそうするRi(C、Y)がCにルートを急速に見つけさせる識別子を含んでいると発表します。 (テーブルインデックス、または実際のメモリアドレス。)
Router B creates a route R(B,Y,Ri(C,Y),C) via router C, it announces it to A, including an identifier Ri(B,Y), internal to B, and used by A as an opaque object.
ルータBはルータCでルートR(B、Y、Ri(C、Y)、C)を作成して、それはRi(B、Y)の、そして、Bへの内部の識別子を含んで、不明瞭な物としてAによって使用されるAにそれを発表します。
Router A creates a route R(A,Y,Ri(B,Y),B) via router B. It has no one to announce it to.
ルータAはルータB.でルートR(A、Y、Ri(B、Y)、B)を作成します。Itには、それを発表するだれもいません。
Now: X originates a datagram addressed to Y. It has no routing information, and sets Ri(Dgram) to zero. It forwards the datagram to router A (X's default gateway).
現在: XはItが、情報を発送させないで、Ri(Dgram)がゼロに合わせるように設定するY.に記述されたデータグラムを溯源します。 それはルータA(Xのデフォルトゲートウェイ)にデータグラムを送ります。
A finds no valid Ri(Dgram), and looks up the destination (Y) in its routing tables. It finds R(A,Y,Ri(B,Y),B), sets Ri(Dgram) <- Ri(B,Y), and forwards the datagram to B.
掘り出し物のノー有効なRi(Dgram)、および経路指定テーブルの目的地(Y)への一見。 それは、Rが(A、Y、Ri(B、Y)、B)であることがわかって、Ri(Dgram)<Ri(B、Y)を設定して、データグラムをBに送ります。
Router B looks at Ri(Dgram) which directly identifies the next hop route R(B,Ri(C,Y),C), sets Ri(Dgram) <- Ri(C,Y) and forwards it to router C.
ルータBは、ルータCに直接、次のホップルートR(B、Ri(C、Y)、C)を特定するRi(Dgram)を見て、Ri(Dgram)<Ri(C、Y)を設定して、それを送ります。
Router C looks at Ri(Dgram) which directly locates R(C,0,Y), sets Ri(Dgram) <- 0 and forwards to Y.
ルータCが直接、R(C、0、Y)の場所を見つけるRi(Dgram)を見て、セットは、YへのRi(Dgram)<0とフォワードです。
Y recognizes its own address in Dest(Dgram), ignores Ri(Dgram).
Ri(Dgram)は、YがDest(Dgram)のそれ自身のアドレスを認識するのを無視します。
Of course, the routers will validate the Ri's received, particularily if they are memory addresses (e.g., M(a) < Ri < M(b), Ri mod N == 0), and probably check that the route in fact describes the destination of the datagram. If the Ri is invalid, the router must use the ordinary method of finding a route (i.e., what it would have done if Ri was 0), and silently ignore the invalid Ri.
もちろん、ルータは受け取られたRiのものを有効にして、それらがメモリアドレス(例えば、M(a)<Ri<M(b)、RiモッズN=0)であるならparticularilyして、たぶん事実上、ルートがデータグラムの目的地について説明するのをチェックするでしょう。 Riが無効であるなら、ルータは、ルートが(すなわち、それがRiが0歳であったならしたこと)であることがわかる普通の方法を使用して、静かに無効のRiを無視しなければなりません。
When a route has been aggregated at some router, implicitly or explicitly, it will find that the incoming Ri(Dgram) at most can identify the aggregation, and it must make a decision; the forwarded datagram then contains the Ri for the specific route. (Note this may happen well upstream of the point at which the routes actually
何らかのルータでルートを集めてあるとき、それとなくか明らかに、高々入って来るRi(Dgram)が集合を特定できるのがわかるでしょう、そして、決定しなければなりません。 そして、進められたデータグラムは特定のルートへのRiを含んでいます。 (これがポイントをよく上流へ起こらせるかもしれないことに注意してください、どれ、実際に発送
Ullmann [Page 16] RFC 1475 TP/IX June 1993
ウルマン[16ページ]RFC1475TP/IX1993年6月
diverge.)
分岐してください。)
This allows all cooperating routers to make immediate forwarding decisions, without any searching of tables or caches once the datagram has entered the routing domain. If the host participates in the routing, at least to the extent of acquiring the initial Ri required from the first router, then only routers that have done aggregations need make decisions. (If the routing changes with datagrams in flight, some router will be required to make a decision to re-rail each datagram.)
これは即座の推進決定をするようにすべての協力にルータを許容します、テーブルかキャッシュを少しも探すのなしでデータグラムがいったん経路ドメインに入ると。 ホストがルーティングに参加するなら、集合をしたルータだけが決定を少なくとも最初のルータから必要である初期のRiを獲得する範囲まで、しなければなりません。 (ルーティングが飛行でデータグラムを交換すると、何らかのルータが各データグラムに再レールを敷くという決定をするのに必要でしょう。)
3.4.2 Flows
3.4.2 流れ
If a "flow" is to be set up, the identifiers are replaced by Flowi(router,route), where each router's structure for the flow contains a pointer to the route on which the flow is built. Datagrams can drop out of the flow at some point, and can be inserted either by the originating host or by a cooperating router near the originator. Since the forward route identifier field is opaque to the sending router, and implicitly meaningful only to the next hop router, use for flows (or similar optimizations) need not be otherwise defined by the protocol. (One presumes that a router issuing both Ri's and Flowi's will take care to make sure that it can distinguish them by some private method.)
「流れ」がセットアップすることであるなら、識別子をFlowi(ルータ、ルート)に取り替えます。そこでは、流れのための各ルータの構造が流れが組立しているルートにポインタを含みます。 データグラムは、何らかのポイントで流れを脱落できて、送信元ホストか創始者の近くの協力ルータで挿入できます。 前進のルート識別子分野が送付ルータに不透明であって、それとなく次のホップルータだけに重要であるので、流れ(または、同様の最適化)の使用は別の方法でプロトコルによって定義される必要はありません。 (人は、RiとFlowiの両方を発行するルータが何らかの個人的な方法でそれらを区別できるのを確実にするために注意されると推定します。)
If a flow has been set up by a restricted target RAP route announcement, it is no different from a route in the implementation. If this announcement originates from the host itself, the Ri in incoming datagrams can be used to determine whether they followed the flow, or to optimize delivery of the datagrams to the next layer protocol.
流れが制限された目標RAPルート発表でセットアップされたなら、ルートと実現において異なっていません。 この発表がホスト自身から発するなら、それらが流れに続いたかどうか決定するか、または次の層のプロトコルにデータグラムの配送を最適化するのに受信データグラムのRiを使用できます。
3.4.3 Mobile hosts
3.4.3 モバイルホスト
First, a definition: A "mobile host" is a host that can move around, connecting via different networks at different times, while maintaining open TCP connections. It is distinguished from a "portable host", which is simply a host that can appear in various places in the net, without continuity. A portable host can be implemented by assigning a new address for each location (more or less automatically), and arranging to update the domain system. Supporting truly mobile hosts is the more interesting problem.
最初に、定義: 「モバイルホスト」は動き回ることができるホストです、いろいろな時間の異なったネットワークを通して接続してオープンなTCP接続を維持している間。 それは単にネットにおける様々な場所に現れることができるホストである「携帯用のホスト」と区別されます、連続なしで。 各位置への新しいアドレスを割り当てることによって携帯用のホストを実行できる、(多少、自動的に)、そして、ドメインシステムをアップデートするように手配すること。 本当に可動のホストを支持するのは、よりおもしろい問題です。
To implement mobile host support in a general way, either some layer of the protocol suite must provide network-wide routing, or the datagrams must be tunnelled from the "home" network of the host to its present location. In the real network, some combination of these is probable: most of the net will forward datagrams toward the home
ザッとモバイルホストサポートを実行するために、プロトコル群の何らかの層がネットワーク全体のルーティングを提供しなければなりませんか、またはホストの「家」ネットワークから現在の位置までデータグラムにトンネルを堀らなければなりません。 本当のネットワークでは、これらの何らかの組み合わせがありえそうです: ネットの大部分は家に向かってデータグラムを送るでしょう。
Ullmann [Page 17] RFC 1475 TP/IX June 1993
ウルマン[17ページ]RFC1475TP/IX1993年6月
network, and then the datagrams will follow a specific host route to the mobile host.
データグラムが特定のホストがモバイルホストに発送する尾行を望んでいるネットワーク、およびその時。
The requirement on the routing system is that it must be able to propagate a host route at least to the home network; any other distribution is useful optimization. When a host route is propagated by RAP as a targeted route, and the routers use the resulting Ri's, the datagram follows an effective tunnel to the mobile host. (Not a real tunnel, in the strict sense; the datagrams are following an actual route at the network protocol layer.)
ルーティングシステムに関する要件はホストルートを少なくともホームネットワークに伝播できなければならないということです。 いかなる他の分配も役に立つ最適化です。 ホストルートが狙っているルートとしてRAPによって伝播されて、ルータが結果として起こるRiのものを使用するとき、データグラムは有効なトンネルにモバイルホストに続きます。 (厳しい意味における本当のトンネル; いずれのデータグラムもネットワークプロトコル層で実際のルートに従っていません。)
As explained in RAP [RFC14XX-RAP], a targeted route can be issued when desired; in particular, it can be triggered by the establishment of a TCP connection or by the arrival of datagrams that do not carry an Ri indicating that they have followed a (non-tunnel) route.
RAP[RFC14XX-RAP]で説明されるように、望んでいると、狙っているルートを発行できます。 特に、TCP接続の設立か(非トンネルの)ルートに従ったのを示すRiを運ばないデータグラムの到着でそれを引き起こすことができます。
4. TCP: Transport protocol
4. TCP: トランスポート・プロトコル
Internet version 7 expands the sizes of the sequence and acknowledgement fields, the window, and the port numbers. This is to remove limitations in version 4 that begin to restrict throughput at (for example) the bandwidth of FDDI and round trip delay of more than 60 milliseconds. At gigabit speeds and delays typical of international links, the version 4 TCP would be a serious limitation. See [RFC1323].
インターネットバージョン7は系列、承認分野、窓、およびポートナンバーのサイズを広くします。 これは、(例えば、)FDDIの帯域幅と60ミリセカンド以上の周遊旅行遅れにおけるスループットを制限し始めるバージョン4における制限を取り除くためのものです。 国際的な関係の典型のギガビット速度と遅れでは、バージョン4TCPは重大な制限でしょう。 [RFC1323]を見てください。
The port numbers are also expanded. This alleviates the problem of going through the entire port number range with a rapid sequence of transactions in less than the lifetime of datagrams in the network.
また、ポートナンバーは広げられます。 これはネットワークにおける、取引の急速な系列がデータグラムの生涯以下にある状態で全体のポートナンバー範囲を通るという問題を軽減します。
4.1 TCP segment header format
4.1 TCPセグメントヘッダー形式
The 64 bit fields (sequence and acknowledgement) in the TCP header are off-phase aligned, in anticipation of the usual case of the TCP header following the 9 32-bit word IP header. If IP options add up to an odd number of 32 bit words, a null option may be added to push the transport header to off-phase alignment.
TCPヘッダーの64ビットの分野(系列と承認)は9の32ビットの単語IPヘッダーについて来るTCPヘッダーの普通のケースを予測して並べられたオフフェーズです。 IPオプションが32ビットの単語の奇数を意味するなら、ヌルオプションは、オフフェーズ整列に輸送ヘッダーを押すために加えられるかもしれません。
Ullmann [Page 18] RFC 1475 TP/IX June 1993
ウルマン[18ページ]RFC1475TP/IX1993年6月
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data offset | MBZ |A|P|R|S|F| checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| destination port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ sequence number +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ acknowledgement number +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| window |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| options ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | データは相殺されます。| MBZ|A|P|R|S|F| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ソースポート| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 仕向港| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + 一連番号+| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + 承認番号+| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 窓| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | オプション… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A description of each field:
それぞれの分野の記述:
4.1.1 Data offset
4.1.1 データは相殺されます。
An 8 bit count of the number of 32 bit words in the TCP header, including any options.
32の数の8ビットのカウントはどんなオプションも含むTCPヘッダーで単語に噛み付きました。
4.1.2 MBZ
4.1.2 MBZ
Reserved bits, must be zero, and must be ignored.
ビットを予約して、ゼロでなければならなく、無視しなければなりません。
4.1.3 Flags
4.1.3 旗
These are the protocol state flags, use exactly as in TCPv4, except that there is no urgent data flag.
これらがプロトコル州旗である、ちょうどどんな緊急のデータもそれを除いたそこのTCPv4にないとき、使用は弛みます。
4.1.4 Checksum
4.1.4 チェックサム
This is a 16 bit checksum of the segment. The pseudo-header used in the checksum consists of the destination address, the source address, the protocol field (constant 6 for TCP), and the 32 bit length of the TCP segment.
これはセグメントの16ビットのチェックサムです。 チェックサムに使用される疑似ヘッダーは送付先アドレス、ソースアドレス、プロトコル分野(TCPのための一定の6)、およびTCPセグメントの32ビットの長さから成ります。
Ullmann [Page 19] RFC 1475 TP/IX June 1993
ウルマン[19ページ]RFC1475TP/IX1993年6月
4.1.5 Source port
4.1.5 ソースポート
The source port number, a 32 bit identifier. See the section on port numbers below.
ソースポート番号、32ビットの識別子。 以下のポートナンバーのセクションを見てください。
4.1.6 Destination port.
4.1.6 仕向港。
The 32 bit destination port number.
32は目的地ポートナンバーに噛み付きました。
4.1.7 Sequence
4.1.7 系列
A 64 bit sequence number, the sequence number of the first octet of user data in the segment.
64ビットの一連番号、セグメントにおける、利用者データの最初の八重奏の一連番号。
The ISN (Initial Sequence Number) generator used in TCPv4 is used in TCPv7, with the 32 bit value loaded into both the high and low 32 bits of the TCPv7 sequence number. This provides reasonable behavior when the 32 bit rollover option is used (see below) for TCPv4 interoperation. V7 hosts must implement the full 64 bit sequence number rollover.
TCPv4で使用されるISN(初期のSequence Number)ジェネレータはTCPv7で使用されます、32ビットの値が上下のビットのTCPv7一連番号の32の両方にロードされている状態で。 32ビットのロールオーバーオプションがTCPv4 interoperationに使用されるとき(以下を見ます)、これは合理的な振舞いを提供します。 V7ホストは64ビットの完全な一連番号ロールオーバーを実装しなければなりません。
4.1.8 Acknowledgement
4.1.8 承認
The 64 bit acknowledgement number, acknowledging receipt of octets up to but not including the octet identified. Valid if the A flag is set, if A is reset (0), this field should be zero, and must be ignored.
八重奏の領収書を八重奏が特定した包含だけでないまで受け取ったことを知らせて、64は承認番号に噛み付きました。 有効である、A旗がAがリセット(0)であるなら設定されるなら、この分野をゼロであるべきであり、無視しなければなりません。
4.1.9 Window
4.1.9 窓
The 32 bit offered window.
32ビットは窓を提供しました。
4.1.10 Options
4.1.10 オプション
TCP options, some of which are documented below.
TCPオプション。それの或るものは以下に記録されます。
4.2 Port numbers
4.2 ポート番号
Port numbers are divided into several ranges: (all numbers are decimal)
ポートナンバーはいくつかの範囲に分割されます: (すべての数が10進です)
0 reserved
1-32767 Internet registered ("well-known") protocols
32768-98303 reserved, to allow TCPv7-TCPv4 conversion
98304 up dynamic assignment
0 ダイナミックな課題で変換98304をTCPv7-TCPv4に許すために予約された1-32767の予約されたインターネット登録された(「よく知られる」)プロトコル32768-98303
It must also be remembered that hosts are free to dynamically assign for active connections any port not actually in use by that host:
また、ホストが活発な接続のために自由にダイナミックに実際にそのホストで使用中でないどんなポートも割り当てることができるのを覚えていなければなりません:
Ullmann [Page 20] RFC 1475 TP/IX June 1993
ウルマン[20ページ]RFC1475TP/IX1993年6月
hosts must not reject connections because the "client" port is in the registered range.
「クライアント」ポートが登録された範囲にあるので、ホストは接続を拒絶してはいけません。
4.3 TCP options
4.3 TCPオプション
4.3.1 Option Format
4.3.1 オプション形式
Each option begins with a 32 bit header:
各オプションは32ビットのヘッダーと共に始まります:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option data ... | padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | オプションデータ… | 詰め物| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.3.2 Null
4.3.2 ヌル
The null option (type = 0), is to be ignored.
ヌルは、(タイプ=0)をゆだねて、無視されることです。
4.3.3 Maximum Segment Size
4.3.3 最大のセグメントサイズ
Maximum segment size (type = 1) specifies the largest segment that the other TCP should send, in terms of the number of data octets. When sent on a SYN segment, it is mandatory; if sent on any other segment it is advisory.
最大のセグメントサイズ(=1をタイプする)はもう片方のTCPが送るはずである中で最も大きいセグメントを指定します、データ八重奏の数に関して。 SYNセグメントで送ると、それは義務的です。 いかなる他のセグメントでも送るなら、顧問です。
Data is one 32 bit word specifying the size in octets.
データは八重奏におけるサイズを指定する1つ32の噛み付いている単語です。
4.3.4 Urgent Pointer
4.3.4 緊急の指針
The urgent pointer (type = 2) emulates the urgent field in TCPv4. Its presence is equivalent to the U flag being set. The data is a 64 bit sequence number identifying the last octet of urgent data. (Not an offset, as in v4.)
緊急の指針(=2をタイプする)はTCPv4の緊急の分野を見習います。 存在は設定されるU旗に同等です。 データは緊急のデータの最後の八重奏を特定する64ビットの一連番号です。 (v4のようなオフセットでない。)
4.3.5 32 Bit rollover
4.3.5 32 噛み付いているロールオーバー
The 32 bit rollover option (type = 3) indicates that only the low order 32 bits of the sequence and acknowledgement packets are significant in the packet.
32ビットのロールオーバーオプション(=3をタイプする)は、安値だけが系列の32ビットを配置するのを示します、そして、確認応答パケットはパケットで重要です。
This is necessary because a converting internet layer gateway has no retained state, and cannot properly set the high order bits. This option must be implemented by version 7 hosts that want to interoperate with version 4 hosts.
変換しているインターネット層のゲートウェイが保有された状態を全く持たないで、適切に高位のビットを設定できないので、これが必要です。 バージョン4ホストと共に共同利用したがっているバージョン7ホストはこのオプションを実装しなければなりません。
Ullmann [Page 21] RFC 1475 TP/IX June 1993
ウルマン[21ページ]RFC1475TP/IX1993年6月
5. UDP: User Datagram protocol
5. UDP: ユーザデータグラムプロトコル
The user datagram protocol is also expanded to include larger port numbers, for reasons similar to the TCP.
また、ユーザデータグラムプロトコルは、TCPと同様の理由で、より大きいポートナンバーを含むように広げられます。
5.1 UDP header format
5.1 UDPヘッダー形式
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data offset | MBZ | checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| destination port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| options ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | データは相殺されます。| MBZ| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ソースポート| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 仕向港| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | オプション… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A description of each field:
それぞれの分野の記述:
5.1.1 Data offset
5.1.1 データは相殺されます。
An 8 bit count of the number of 32 bit words in the UDP header, including any options.
32の数の8ビットのカウントはどんなオプションも含むUDPヘッダーで単語に噛み付きました。
5.1.2 MBZ
5.1.2 MBZ
Reserved bits, must be zero, and must be ignored.
ビットを予約して、ゼロでなければならなく、無視しなければなりません。
5.1.3 Checksum
5.1.3 チェックサム
This is a 16 bit checksum of the datagram. The pseudo-header used in the checksum consists of the destination address, the source, address, and the protocol field (constant 17 for UDP), and the 32 bit length of the user datagram.
これはデータグラムの16ビットのチェックサムです。 チェックサムに使用される疑似ヘッダーはユーザデータグラムの送付先アドレス、ソース、アドレス、プロトコル分野(UDPのための一定の17)、および32ビットの長さから成ります。
5.1.4 Source port
5.1.4 ソースポート
The source port number, a 32 bit identifier. See the section on TCP port numbers above.
ソースポート番号、32ビットの識別子。 TCPポートナンバーのセクションが上であることを見てください。
5.1.5 Destination port.
5.1.5 仕向港。
The 32 bit destination port number.
32は目的地ポートナンバーに噛み付きました。
Ullmann [Page 22] RFC 1475 TP/IX June 1993
ウルマン[22ページ]RFC1475TP/IX1993年6月
5.1.6 Options
5.1.6 オプション
UDP options, none are presently defined.
UDPオプションであり、なにも現在、定義されません。
6. ICMP
6. ICMP
The ICMP protocol is very similar to ICMPv4, in some cases not requiring any conversion.
いくつかの場合、少しの変換も必要としないで、ICMPプロトコルはICMPv4と非常に同様です。
The complication is that IP datagrams are nested within ICMP messages, and must be converted. This is discussed later.
複雑さはIPデータグラムをICMPメッセージの中で入れ子にされて、変換しなければならないということです。 後でこれについて議論します。
6.1 ICMP header format
6.1 ICMPヘッダー形式
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type | code | checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type-specific parameter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type-specific data ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| コード| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ特有のパラメタ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ特有のデータ… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type and code are well-known values, defined in [RFC792]. The codes have meaning only within a particular type, they are not orthogonal.
タイプとコードは[RFC792]で定義されたよく知られる値です。 コードは特定のタイプだけの中に意味を持っていて、それらは直交していません。
The next 32 bit word is usually defined for the specific type, sometimes it is unused.
通常、次の32ビットの単語は特定のタイプのために定義されて、時々、それは未使用です。
For many types, the data consists of a nested IP datagram, usually truncated, which is a copy of the datagram causing the event being reported. In IPv4, the nested datagram consists of the IP header, and another 64 bits (at least) of the original datagram.
多くのタイプのために、データは通常、先端を切られた報告されるイベントを引き起こすデータグラムのコピーである入れ子にされたIPデータグラムから成ります。 IPv4では、入れ子にされたデータグラムはIPヘッダー、およびオリジナルのデータグラムのもう64ビット(少なくとも)から成ります。
For IPv7, the nested datagram must include the IP header plus 96 bits of the remaining datagram (thus including the port numbers within TCP and UDP), and should include the first 256 bytes of the datagram. I.e., in most cases where the original datagram was not large, it will return the entire datagram.
IPv7に関しては、入れ子にされたデータグラムは、IPヘッダーと96ビットの残っているデータグラム(その結果、TCPとUDPの中にポートナンバーを含んでいる)を含まなければならなくて、データグラムの最初の256バイトを含んでいるはずです。 すなわち、多くの場合オリジナルのデータグラムが大きくなかったところに、それは全体のデータグラムを返すでしょう。
6.2 Conversion failed ICMP message
6.2 変換の失敗したICMPメッセージ
The introduction of network layer conversion requires a new message type, to report conversion errors. Note that an invalid datagram should result in the sending of some other ICMP message (e.g., parameter problem) or the silent discarding of the datagram. This message is only sent when a valid datagram cannot be converted.
ネットワーク層変換の導入は、変換誤りを報告するために新しいメッセージタイプを必要とします。 無効のデータグラムがある他のICMPメッセージ(例えば、パラメタ問題)の発信かデータグラムを静かな捨てることをもたらすはずであることに注意してください。 有効なデータグラムを変換できないときだけ、このメッセージを送ります。
Ullmann [Page 23] RFC 1475 TP/IX June 1993
ウルマン[23ページ]RFC1475TP/IX1993年6月
Note: implementations are not expected to, and should not, check the validity of incoming datagrams just to accomplish this; it simply means that an error detected during conversion that is known to be an actual error in the incoming datagram should be reported as such, not as a conversion failure.
以下に注意してください。 そして、実装が予想されない、受信データグラムの正当性をチェックして、ただこれを達成してください;であるべきです それは、受信データグラムの実際の誤りであることが知られている変換の間に検出された誤りが変換失敗として報告されるのではなく、そのようなものとして報告されるべきであることを単に意味します。
Note that the conversion failed ICMP message may be sent in either the IPv4 or IPv7 domain; it is a valid ICMP message type for IPv4.
変換の失敗したICMPメッセージがIPv4かIPv7ドメインで送られるかもしれないことに注意してください。 それはIPv4のための有効なICMPメッセージタイプです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type | code | checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| pointer to problem area |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| copy of datagram that could not be converted .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| コード| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 問題領域への指針| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 変換できなかったデータグラムのコピー… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The type for Conversion Failed is 31.
Conversion Failedのためのタイプは31歳です。
The codes are:
コードは以下の通りです。
0 Unknown/unspecified error
1 Don't Convert option present
2 Unknown mandatory option present
3 Known unsupported option present
4 Unsupported transport protocol
5 Overall length exceeded
6 IP header length exceeded
7 Transport protocol > 255
8 Port conversion out of range
9 Transport header length exceeded
10 32 Bit Rollover missing and ACK set
11 Unknown mandatory transport option present
Convertオプション現在の2Unknownではなく、現在のオプションの非サポート・オプション現在の4Unsupported3Knownトランスポート・プロトコル5Overallの長さが6IPヘッダ長を超えていたのが義務的な0の未知の、または、不特定の誤り1ドンが7Transportプロトコル>を超えていた、255、8Port変換、9Transportヘッダ長が超えていた範囲から、10 32のBit Rolloverの取り逃がすのとACKは11のUnknownの義務的な輸送オプションプレゼントを設定します。
The use of code 0 should be avoided, any other condition found by implementors should be assigned a new code requested from IANA. When code 0 is used, it is particularily important that the pointer be set properly.
コード0の使用は避けられるべきであり、IANAから要求された新法は作成者によって見つけられたいかなる他の状態にも割り当てられるべきです。 コード0が使用されているとき、指針が適切に設定されるのは、particularilyに重要です。
The pointer is an offset from the start of the original datagram to the beginning of the offending field.
オリジナルのデータグラムの始まりから怒っている分野の始まりまで指針はオフセットです。
The data is part of the datagram that could not be converted. It must be at least the IP and transport headers, and must include the field pointed to by the previous parameter. For code 4, the transport header is probably not identifiable; the data should
データは変換できなかったデータグラムの一部です。 それは、少なくともIPと輸送ヘッダーでなければならなく、前のパラメタによって示された野原を含まなければなりません。 コード4において、輸送ヘッダーはたぶん身元保証可能ではありません。 データはそうするべきです。
Ullmann [Page 24] RFC 1475 TP/IX June 1993
ウルマン[24ページ]RFC1475TP/IX1993年6月
include 256 bytes of the original datagram.
オリジナルのデータグラムの256バイトを含めてください。
7. Notes on the domain system
7. ドメインシステムに関する注
7.1 A records
7.1 記録
Address records will be added to the IN (Internet) zone with IPv7 addresses for all hosts as IPv7 is deployed. Eventually the IPv4 addresses will be removed. As mentioned above, the AD (Administrative Domain) space is initially assigned so that the first 4 octets of a v7 address cannot be confused with a v4 address (or, rather, the confusion will be to no effect.)
IPv7が配布されるので、アドレス記録はすべてのホストのためにIPv7アドレスでIN(インターネット)ゾーンに追加されるでしょう。 結局、IPv4アドレスを取り除くでしょう。 以上のように、AD(管理Domain)スペースは、初めは、v7アドレスの最初の4つの八重奏がv4アドレスに混乱できないように、割り当てられます。(むしろ、どんな効果にはも混乱がないでしょう。)
For example:
例えば:
DELTA.Process.COM. A 192.42.95.68
A 192.0.0.192.42.95.1.68
DELTA.Process.COM。 A192.42.95、.68、A192.0.0、.192、.42、.95、.1、.68
It is important that the A record be used, to avoid the cache consistancy problem that would arise when different records had different remaining TTLs.
A記録が異なった記録に異なった残っているTTLsがあったとき起こるキャッシュconsistancy問題を避けるのに使用されるのは、重要です。
Note that if an unmodified version of the more popular public domain nameserver is a secondary for a zone containing IPv7 addresses, it will erroneously issue RRs with only the first four bytes. (I.e., 192.0.0.192 in the example.) This is another reason to ensure that the AD numbers are initially reserved out of the IPv4 network number space. Eventually, zones with IPv7 addresses would be expected to be served only by upgraded servers.
よりポピュラーな公共の場ネームサーバの変更されていないバージョンがIPv7アドレスを含むゾーンへの2番目であるなら、最初の4バイトだけで誤ってRRsを発行することに注意してください。 すなわち、(192.0 .0 .192 例で) これはAD番号が初めはIPv4ネットワーク・ナンバースペースから予約されるのを保証する別の理由です。 結局、アップグレードしたサーバだけによってIPv7アドレスがあるゾーンが役立たれると予想されるでしょう。
7.2 PTR zone
7.2 PTRゾーン
The inverse (PTR) zone is .#, with the IPv7 address (reversed). I.e., just like .IN-ADDR.ARPA, but with .# instead.
逆さの(PTR)ゾーンはそうです。. IPv7アドレスがある#逆にされます()。 . すなわち、まさしく.IN-ADDR.ARPAにもかかわらず、代わりに#で。
This respects the difference in actual authority: the NSF/DDN NIC is the authority for the entire space rooted in .IN-ADDR.ARPA. in the v4 Internet, while in the new Internet it holds the authority only for the AD 0.0.192.#. (Plus, of course, any other ADs assigned to it over time.)
これは実際の権威の違いを尊敬します: NSF/DDN NICは.IN-ADDR.ARPAに根づいている全体のスペースへの権威です。新しいインターネットにある間、v4インターネットでは、それはAD0.0.192#のためだけの権威を保持します。(もちろん、そのうえ、時間がたつにつれてそれに割り当てられたいかなる他のADsも。)
8. Conversion between version 4 and version 7
8. バージョン4とバージョン7の間の変換
As noted in the description of datagram format, it is possible to provide a mostly-transparent bridge between version 4 and version 7.
データグラム形式の記述で注意されるように、バージョン4とバージョン7の間にほとんど透明なブリッジを提供するのは可能です。
This discusses TCP and ICMP at the session/transport layer; UDP is a subset of the TCP conversion. Most protocols at this layer will
これはセッション/トランスポート層でTCPとICMPについて議論します。 UDPはTCP変換の部分集合です。 この層のほとんどのプロトコルはそうするでしょう。
Ullmann [Page 25] RFC 1475 TP/IX June 1993
ウルマン[25ページ]RFC1475TP/IX1993年6月
probably need no translation; however it will probably be necessary to specify exactly which will have translations done.
たぶん翻訳を全く必要としない、。 しかしながら、たぶん、ちょうどどれで翻訳を完了するかを指定するのが必要でしょう。
New protocols at the session/transport layer defined over IPv7 should have protocol numbers greater than 255, and will not be translated to IPv4.
IPv7の上で定義されたセッション/トランスポート層の新しいプロトコルは、255以上のプロトコル番号を持つべきであり、IPv4に翻訳されないでしょう。
Most of the translations should consist of copying various fields, verifying fixed values in the datagram being translated, and setting fixed values in the datagram being produced. In general, the checksum must be verified first, and then a new checksum computed for the generated datagram.
翻訳の大部分は多岐をコピーするのから成るべきです、翻訳されて、生産されるデータグラムに一定の価値をはめ込むのであるのでデータグラムで一定の価値について確かめて。 一般に、最初にチェックサムについて確かめなければなりませんでした、そして、次に、新しいチェックサムは発生しているデータグラムのために計算されました。
8.1 Version 4 IP address extension option
8.1 バージョン4IPアドレス拡大オプション
A new option is defined for IP version 4, to carry the extended addresses of IPv7. This will be particularily useful in the initial testing of IPv7, during a time when most of the fabric of the internet is IPv4. An IPv7 host will be able to connect to another IPv7 host anywhere in the internet even though most of the paths and routers are IPv4, and still use the full addressing. This will continue to work until non-unique network numbers are assigned, by which time most of the infrastructure should be IPv7.
新しいオプションはIPバージョン4のために広げるのが記述するIPv7のキャリーと定義されます。 これはIPv7の初期のテストで役に立つparticularilyになるでしょう、インターネットの織物の大部分がIPv4である時。 IPv7ホストは、経路とルータの大部分がIPv4ですが、インターネットでどこでも別のIPv7ホストに接して、まだ完全なアドレシングを使用できるでしょう。 非ユニークなネットワーク・ナンバーがインフラストラクチャの大部分がどの時にIPv7であるべきであるかによって割り当てられるまで、これは、働き続けるでしょう。
8.1.1 Option format
8.1.1 オプション形式
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type (147) | length = 10 | source IPv7 AD number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | src 7th octet | destination IPv7 AD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| number ... | dst 7th octet |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (147)をタイプしてください。| 長さ=10| ソースIPv7AD番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | src7番目の八重奏| 目的地、IPv7西暦| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 数… | dst7番目の八重奏| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The source and destination are in IPv4 order (source first), for consistancy. The type code is 147.
ソースと目的地がconsistancyのIPv4注文(最初に、出典を明示する)にあります。 タイプコードは147です。
8.2 Fragmented datagrams
8.2 断片化しているデータグラム
Datagrams that have been fragmented must be reassembled by the converting host or router before conversion. Where the conversion is being done by the destination host (i.e., the case of a v7 host receiving v4 datagrams), this is similar to the present fragmentation model.
変換の前に変換しているホストかルータで断片化されたデータグラムを組み立て直さなければなりません。 あて先ホスト(すなわち、v4データグラムを受け取るv7ホストのケース)が変換を完了しているところでは、これは現在の断片化モデルと同様です。
When it is being done by an intermediate router (acting as an internetwork layer gateway) the router should use all of source, destination, and datagram ID for identification of IPv4 fragments;
中間的ルータでそれをしているとき(インターネットワーク層のゲートウェイとして機能して)、ルータはIPv4断片の識別にソース、目的地、およびデータグラムIDのすべてを使用するべきです。
Ullmann [Page 26] RFC 1475 TP/IX June 1993
ウルマン[26ページ]RFC1475TP/IX1993年6月
note that destination is used implicitly in the usual reassembly at the destination. When reassembling an IPv7 datagram, the 128 bit fragment ID is used as usual.
目的地が目的地の普通の再アセンブリでそれとなく使用されることに注意してください。 IPv7データグラムを組み立て直すとき、128ビットの断片IDはいつものように使用されます。
If the fragments take different paths through the net, and arrive at different conversion points, the datagram is lost.
断片がネットを通して異なった経路を取って、異なった変換ポイントに届くなら、データグラムは無くなっています。
8.3 Where does the conversion happen?
8.3 どこで、変換は起こりますか?
The objective of conversion is to be able to upgrade systems, both hosts and routers, in whatever order desired by their owners. Organizations must be able to upgrade any given system without reconfiguration or modification of any other; and IPv4 hosts must be able to interoperate essentially forever. (IPv4 routers will probably be effectively eliminated at some point, except where they exist in their own remote or isolated corners.)
変換の目的はシステムをアップグレードさせることであることができます、ホストといかなるオーダーにおけるルータの両方も彼らの所有者で望んでいました。 組織は再構成も変更なしでいかなる他のもどんな与えられたシステムもアップグレードさせることができなければなりません。 そして、IPv4ホストはいつまでも、本質的には共同利用できなければなりません。(IPv4ルータはたぶん何らかのポイントで事実上排除されるでしょう、それらがそれら自身のリモートであるか孤立している角に存在するところを除いて。)
Each TCP/IP v7 system, whether host or router, must be able to recognize adjacent systems in the topology that are (only) v4, and call the appropriate conversion routine just before sending the datagram.
それぞれのTCP/IP v7システムは、トポロジーの(単に)v4である隣接しているシステムを認識して、データグラムを送るすぐ前に、ホストかルータであることにかかわらず適切な変換ルーチンを呼ぶことができなければなりません。
Digression: I believe v7 hosts will get much better performance by doing everything internally in v7, and using conversion to filter datagrams when necessary. This keeps the usual code path simple, with only a "hook" right after receiving to convert incoming IPv4 datagrams, and just before sending to convert to IPv4. Routers may prefer to keep datagrams in their incoming version, at least until after the routing decision is made, and then doing the conversion only if necessary. In either case, this is an implementation specific decision.
脱線: 私は、必要であるときに、v7で内部的にすべてをするのによるはるかに良い性能と、変換を使用するとv7ホストがデータグラムをフィルターにかけにさせられると信じています。 これは普通のコード経路を簡単に保ちます、入って来るIPv4データグラムを変換するために受信する直後、IPv4に変えるためにまさしく発信する前の「フック」だけで。 ルータは、それらの入って来るバージョンにデータグラムを保つのを好むかもしれません、次に、必要ならだけ、ルーティング決定が少なくとも作られていて、変換した後まで。 どちらかの場合では、これは実現の特定の決定です。
It must be noted that any forwarding system may convert datagrams to IPv7, then back to IPv4, even if that loses information such as unknown options. The reverse is not acceptable: a system that receives an IPv7 datagram should not convert it to IPv4, then back to IPv7 on forwarding.
どんな転送システムもデータグラムをIPv7に変換するかもしれないことに注意しなければなりません、そして、IPv4に、それが未知のオプションなどの情報を失っても。 逆は許容できません: IPv7データグラムを受けるシステムは推進のときにIPv4と、そして、そして、IPv7にそれを変換して戻すはずがありません。
The preferred method for identifying which hosts require conversion is to ARP first for the IPv7 address, and then again if no response is received, for the IPv4 address. The reservation of ADs out of the v4 network number space is useful again here, protecting hosts that fail to properly use the ARP address length fields.
最初に、IPv7アドレスと次に、一方、IPv4アドレスのために応答を全く受けないかどうかARPにはどのホストが変換を必要とするかを特定するための適した方法があります。 v4ネットワーク・ナンバースペースからのADsの予約は再びここで役に立ちます、適切にARPアドレス長さの分野を使用しないホストを保護して。
On networks where ARP is not normally used, the method is to assume that a remote system is v7. If an IPv7 datagram is received from it, the assumption is confirmed. If, after a short time, no IPv7 datagram is received, a v7 ICMP echo is sent. If a reply is received
通常、ARPが使用されないネットワークでは、方法はリモートシステムがv7であると仮定することです。 それからIPv7データグラムを受け取るなら、仮定を確認します。 どんなIPv7データグラムも短い間の後に受け取られていないなら、v7 ICMPエコーを送ります。 回答が受け取られているなら
Ullmann [Page 27] RFC 1475 TP/IX June 1993
ウルマン[27ページ]RFC1475TP/IX1993年6月
(in either version) the assumption is confirmed.
(どちらかのバージョンの) 仮定は確認されます。
If no reply is recieved, the remote system is assumed not to understand IPv7, and datagrams are converted to IPv4 just before transmitting them.
回答が全くrecievedされないなら、リモートシステムがIPv7を理解していないと思われて、それらを伝えるすぐ前に、データグラムはIPv4に変換されます。
Implementations should also provide for explicit configuration where desired.
また、実現は必要であるところに明白な構成に備えるべきです。
8.4 Hybrid IPv4 systems
8.4 ハイブリッドIPv4システム
In the course of implementing IPv7, especially in constrained environments such as small terminal servers, it may be useful to implement the IPv4 address extension option directly, thereby regaining universal connectivity.
特に小さい端末のサーバなどの強制的な環境でIPv7を実行することの間に、直接IPv4アドレス拡大オプションを実行するのは役に立つかもしれません、その結果、普遍的な接続性を取り戻します。
This may also be a useful interim step for vendors not prepared to do a major rework of an implementation; but it is important not to get stalled in this step.
また、これによる少佐をする用意ができていない業者にとって、役に立つ中間の段階が実現を作りなおすということであるかもしれません。 しかし、このステップで停頓しないのは重要です。
A hybrid IPv4 + address extension system does not have to implement the conversion, it places this onus on its neighbors. It may itself have an address with the subnet extension (7th byte) not equal to 1.
ハイブリッドIPv4+アドレス拡大システムは変換を実行する必要はなくて、それはこの重荷を隣人に置きます。 それがそうするかもしれない、それ自体、1と等しくないサブネット拡大(7番目のバイト)を伴うアドレスを持ってください。
The implication of hybrid systems is that it is not valid to assume that a host with a IPv7 address is a native IPv7 implementation.
ハイブリッドシステムの含意はIPv7アドレスをもっているホストがネイティブのIPv7実現であると仮定するのが有効でないということです。
8.5 Maximum segment size in TCP
8.5 TCPの最大のセグメントサイズ
It is probably advisable for IPv4 implementations to reduce the MSS offered by a small amount where possible, to avoid fragmentation when datagrams are converted to IPv7. This arises when IPv4 hosts are communicating through an IPv7 infrastructure, with the same MTU as the local networks of the hosts.
IPv4実現が少量によって可能であるところに提供されたMSSを減少させるのは、データグラムがIPv7に変換されるとき、断片化を避けるためにたぶん賢明です。 IPv4ホストがIPv7インフラストラクチャを通って交信する予定であるとき、これは起こります、ホストの企業内情報通信網と同じMTUと共に。
8.6 Forwarding and redirects
8.6、進めて、向け直す。
It may be important for a router to not send ICMP redirects when it finds that it must do a conversion as part of forwarding the datagram. In this case, the hosts involved may not be able to interact directly. The IPv7 host could ignore the redirect, but this results in an unpleasant level of noise as the sequence continually recurs.
ルータがICMPを送らないのがいつを向け直すかは、重要であるかもしれません。それは、データグラムを進める一部として変換しなければならないのがわかります。 この場合、かかわったホストは直接相互作用できないかもしれません。 IPv7ホストは再直接を無視できましたが、系列が絶えず再発するのに従って、これは不快なレベルの雑音をもたらします。
8.7 Design considerations
8.7 デザイン問題
The conversion is designed to be fairly efficient in implementation, especially on RISC architectures, assuming they can either do a
aができると仮定して、変換は、特にRISC構造で実現でかなり効率的になるように設計されています。
Ullmann [Page 28] RFC 1475 TP/IX June 1993
ウルマン[28ページ]RFC1475TP/IX1993年6月
conditional move (or store), or do a short forward branch without losing the instruction cache. The other conditional branches in the body of the code are usually not-taken out to the failure/discard case.
条件付きである、インストラクションキャッシュを失わないで、動くか(または、店)、または短い前進のブランチをしてください。 コードのボディーの他の条件付き分岐は通常、失敗/破棄への外で取られなかったケースです。
Handling options does involve a loop and a dispatch (case) operation. The options in IPv4 are more difficult to handle, not being designed for speed on a 32 bit aligned RISCish architecture, but they do not occur often, except perhaps the address extension option.
オプションを扱うと、輪と発信(ケース)操作はかかわります。 IPv4のオプションは扱うのが、より難しい、32ビットの速度のために設計されていないのがRISCish構造を並べましたが、頻出しません、恐らくアドレス拡大オプションを除いて。
For CISC machines, the same considerations will lead to fairly efficient code.
CISCマシンに関しては、同じ問題は効率的なコードに公正につながるでしょう。
The conversion code must be extremely careful to be robust when presented with invalid input; in particular, it may be presented with truncated transport layer headers when called recursively from the ICMP conversion.
換算相場は無効の入力を与えるとき、強健であるのに非常に慎重でなければなりません。 ICMP変換から再帰的に呼ぶと、特に、端が欠けているトランスポート層ヘッダーをそれに与えるかもしれません。
8.8 Conversion from IPv4 to IPv7
8.8 IPv4からIPv7までの変換
Individual steps in the conversion; the order is in most cases not significant.
変換における独特のステップ。 多くの場合、オーダーは重要ではありません。
o Verify checksum.
o チェックサムについて確かめてください。
o Verify fragment offset is 0, MF flag is 0.
o 断片について確かめてください。オフセットは0、MF旗が0であるということです。
o Verify version is 4.
o 検証、バージョンは4です。
o Extend TTL to 16 bits, multiply by 16.
o TTLを16ビットまで広げてください、そして、16で増えてください。
o Set forward route identifier to 0.
o 前進のルート識別子を0に設定してください。
o Set first 3 octets of destination to AD (i.e., 192.0.0), copy
first three octets from v4 address, set next octet to 1, copy
last octet. (This can be done with shift/mask/or operations
on most architectures.)
o すなわち、目的地の最初の3つの八重奏をADに設定してください、(192.0、.0、)、v4アドレスから最初の3つの八重奏をコピーしてください、そして、次の八重奏を1に設定してください、そして、最後の八重奏をコピーしてください。 これはそうであることができます。(シフト/マスク/か操作をほとんどの構造に処理する、)
o Do the same translation on source address.
o ソースアドレスで同じ翻訳をしてください。
o Copy protocol, set high 8 bits to zero.
o プロトコルをコピーしてください、そして、8ビットをゼロに高く設定してください。
o If DF flag set, add Don't Fragment option.
o DFがセットに旗を揚げさせるなら、Fragmentオプションではなく、ドンを加えてください。
o If Address Extension option present, copy ADs and subnet
extension numbers into destination and source.
o Address Extensionオプションプレゼントであるなら、ADsとサブネット内線電話番号を目的地とソースにコピーしてください。
o Convert other options where possible. If an unknown option
o 可能であるところで別の選択肢を変換してください。 未知のオプションです。
Ullmann [Page 29] RFC 1475 TP/IX June 1993
ウルマン[29ページ]RFC1475TP/IX1993年6月
with copy-on-fragment is found, fail. If copy-on-fragment is
not set, ignore the option. I.e., the flag is (ab)used as an
indicator of whether the option is mandatory.
断片の上のコピーは見つけられて、失敗してください。 断片の上のコピーが設定されないなら、オプションを無視してください。 すなわち、旗はオプションが義務的であるかどうかに関するインディケータとして使用される(腹筋)です。
o Compute new IP header length.
o 新しいIPヘッダ長を計算してください。
o Convert session/transport layer (TCP) header and data.
o セッション/トランスポート層(TCP)ヘッダーとデータを変換してください。
o Compute new overall datagram length.
o 新しい総合的なデータグラムの長さを計算してください。
o Calculate IPv7 checksum.
o IPv7チェックサムについて計算してください。
8.9 Conversion from IPv7 to IPv4
8.9 IPv7からIPv4までの変換
The steps to convert IPv7 to IPv4 follow. Note that the converting router or host is partly in the role of destination host; it checks both bits of class in IP options, and (as in the other direction) must reassemble fragmented datagrams.
IPv7をIPv4に変換する方法は従います。 一部あて先ホストの役割には変換ルータかホストがいることに注意してください。 それは、IPオプションにおける、クラスの両方のビットをチェックして、断片化しているデータグラムを組み立て直さなければなりません(もう片方の指示のように)。
o Verify checksum.
o チェックサムについて確かめてください。
o Verify version is 7
o 検証、バージョンは7です。
o Set type-of-service to 0 (there may be an option defined,
that will be handled later).
o サービスのタイプを0に設定してください(定義されたオプションがあるかもしれなくて、それは後で扱われるでしょう)。
o If length is greater than (about) 65563, fail. (That number
is not a typographical error. Note that the IPv7+TCPv7
headers add up to 28 bytes more than the corresponding v4
headers in the usual case.) This check is only to avoid
useless work, the precise check is later.
o 長さが(about)65563より大きいなら、失敗してください。 (その数は誤字ではありません。 IPv7+TCPv7ヘッダーが普通の場合で対応するv4ヘッダーより最大28バイトもう少し加えることに注意してください。) このチェックが単に役に立たない仕事を避けることであり、正確なチェックは、より遅れています。
o Generate an ID (using an ISN based sequence generator,
possibly also based on destination or source or both).
o ID(ISNのベースの系列ジェネレータを使用して、また、ことによると目的地、ソースまたは両方に基づいている)を発生させてください。
o Set flags and fragment field to 0.
o 旗と断片分野を0に設定してください。
o Divide TTL by 16, if zero, fail (send ICMP Time Exceeded).
If greater that 255, set to 255.
o 16の分水嶺TTLはゼロであるなら失敗します(ICMP Time Exceededを送ってください)。 より大きい、255に設定されたその255
o If next layer protocol is greater than 255, fail. Else copy.
o 次の層のプロトコルが255以上であるなら、失敗してください。 ほかに、コピーしてください。
o Copy first 3 octets and 8th octet of destination to
destination address.
o 目的地の最初の3つの八重奏と8番目の八重奏を送付先アドレスにコピーしてください。
o Same for source address.
o ソースアドレスにおいて、同じです。
o Generate v4 address extension option. (If enabled; this
o v4アドレス拡大オプションを発生させてください。 (可能にされるなら;これ
Ullmann [Page 30] RFC 1475 TP/IX June 1993
ウルマン[30ページ]RFC1475TP/IX1993年6月
probably should be a configuration option, should default to
on.)
たぶんa設定オプションであるべきであり、デフォルトとするべきである、オンである、)。
o Process v7 options. If any unknown options of class not 0
found, fail.
o v7オプションを処理してください。 どんな0も見つけなかったクラスのあらゆる未知のオプションであるなら、失敗してください。
o If Don't Fragment option found, set DF flag.
o オプションが見つけたFragmentではなく、ドンであるなら、セットDFは弛みます。
o If Don't Convert option found, fail.
o オプションが見つけたConvertではなく、ドンであるなら、失敗してください。
o Convert other options where possible, or fail.
o 可能であるところで別の選択肢を変換するか、または失敗してください。
o Compute new IP header length. This may fail (too large),
fail conversion if so.
o 新しいIPヘッダ長を計算してください。 これは、失敗して(大き過ぎる)、そうだとすれば、変換に失敗するかもしれません。
o Convert session/transport layer (e.g., TCP).
o セッション/トランスポート層(例えば、TCP)を変換してください。
o Compute new overall datagram length. If greater than 65535,
fail.
o 新しい総合的なデータグラムの長さを計算してください。 65535以上であるなら、失敗してください。
o Compute IPv4 checksum.
o IPv4チェックサムを計算してください。
8.10 Conversion from TCPv4 to TCPv7
8.10 TCPv4からTCPv7までの変換
o Subtract header words from v4 checksum. (Note that this is
actually done with one's complement addition.)
o v4チェックサムからのヘッダー単語を引き算してください。 (実際に1の補数添加でこれをすることに注意してください。)
o Copy flags (except for Urgent).
o コピーは弛みます(Urgentを除いて)。
o If source port is less than 32768 (a sign condition test will
suffice on most architectures), copy it. If equal or
greater, add 65536.
o ソース港が32768(正負条件テストはほとんどの構造で十分である)未満であるなら、それをコピーしてください。 等しいか、または、より大きいなら、65536を加えてください。
o Same operation on destination port.
o 仕向港における同じ操作。
o Copy sequence to low 32 bits, set high to 0.
o 系列を高い0に設定された低32ビットまでコピーしてください。
o Copy acknowledgement to low 32 bits, set high to 0.
o 承認を高い0に設定された低32ビットまでコピーしてください。
o Copy window. (The TCPv4 performance extension [RFC1323]
window-scale cannot be used, as it would require state; we
use the basic window offered.)
o 窓をコピーしてください。 (状態を必要とするようにTCPv4性能拡張子[RFC1323]窓スケールを使用できません; 私たちは提供された基本的な窓を使用します。)
o Add 32 bit rollover option.
o 32ビットのロールオーバーオプションを加えてください。
o Convert maximum segment size option if present.
o 存在しているなら、最大のセグメントサイズオプションを変換してください。
o Compute data offset and copy data.
o データオフセットとコピーデータを計算してください。
Ullmann [Page 31] RFC 1475 TP/IX June 1993
ウルマン[31ページ]RFC1475TP/IX1993年6月
o Add header words into saved checksum. It is important not to
recompute the checksum over the data; it must remain an
end-to-end checksum.
o 救われたチェックサムにヘッダー単語を加えてください。 データの上でチェックサムを再計算しないのは重要です。 それは終わりから終わりへのチェックサムのままで残らなければなりません。
o Return to IP layer conversion.
o IP層の変換に戻ってください。
8.11 Conversion from TCPv7 to TCPv4
8.11 TCPv7からTCPv4までの変換
o Subtract header from v7 checksum.
o v7チェックサムからヘッダーを引き算してください。
o If source port is greater than 65535, subtract 65536. If
result is still greater than 65535, fail. (Send ICMP
conversion failed/port conversion out of range. The sending
host may then reset its port number generator to 98304.)
o ソース港が65535以上であるなら、65536を引き算してください。 それでも、結果が65535以上であるなら、失敗してください。 (失敗した/ポート変換を範囲からICMP変換に送ってください。 そして、送付ホストはポートナンバージェネレータを98304にリセットするかもしれません。)
o Same translation for destination port.
o 仕向港のための同じ翻訳。
o Copy low 32 bits of sequence number.
o 一連番号の低32ビットをコピーしてください。
o If A bit set, copy low 32 bits of acknowledgement.
o Aがセットに噛み付いたなら、承認の低32ビットをコピーしてください。
o Copy flags.
o コピーは弛みます。
o If window is greater than 61440, set it to 24576. If less,
copy it unchanged. (Rationale for the 24K figure: this has
been found to be a good default for IPv4 hosts. If the IPv7
host is offering a very large window, the IPv4 host probably
isn't prepared to play at that level.)
o 窓が61440以上であるなら、24576にそれを設定してください。 より少ないなら、変わりがない状態でそれをコピーしてください。 (24Kの図のための原理: これはIPv4ホストにとって、良いデフォルトであることがわかりました。 IPv7ホストが非常に大きい窓を提供しているなら、IPv4ホストはたぶんおまけに、レベルをプレーする用意ができていません。)
o Process options. If 32 Bit Rollover is not present, and A
flag is set, fail. (Send ICMP conversion failed/32 bit
Rollover missing.)
o オプションを処理してください。 32Bit Rolloverが存在していなくて、A旗が設定されるなら、失敗してください。 (失敗した/32をICMP変換に噛み付いているRolloverなくなった状態で送ってください。)
o If Urgent is present, compute offset. If in segment, set U
flag and offset field. If not, ignore.
o Urgentが存在しているなら、オフセットを計算してください。 セグメントでU旗を設定してください、そして、分野を相殺してください。 そうでなければ、無視します。
o Convert Maximum Segment Size option. If greater than 16384,
set to 16384.
o Maximum Segment Sizeオプションを変換してください。 16384以上であるなら、16384にセットしてください。
o Compute new data offset.
o 新しいデータオフセットを計算してください。
o Add header words into v4 checksum.
o v4チェックサムにヘッダー単語を加えてください。
o Return to IP layer conversion.
o IP層の変換に戻ってください。
Ullmann [Page 32] RFC 1475 TP/IX June 1993
ウルマン[32ページ]RFC1475TP/IX1993年6月
8.12 ICMP conversion
8.12 ICMP変換
ICMP messages are converted by copying the type and code into the new packet, and copying the other type-specific fields directly.
ICMPメッセージは、新しいパケットにタイプとコードをコピーして、直接他のタイプ特有の分野をコピーすることによって、変換されます。
If the message contains an encapsulated, and usually truncated, IP datagram, the conversion routine is called recursively to translate it as far as possible. There are some special considerations:
メッセージが要約の、そして、通常端が欠けているIPデータグラムを含んでいるなら、変換ルーチンは、それをできるだけ翻訳するために再帰的に呼ばれます。 いくつかの特別な問題があります:
o The encapsulated datagram is less likely to be valid, given
that it did generate an error of some kind.
o ある種の誤りを発生させたなら、要約のデータグラムはそれほど有効である傾向がありません。
o The conversion should attempt to complete all fields
available, even if some would cause failures in the general
case. Note, in particular, that in the course of converting
a datagram, when a failure occurs, an ICMP message
(conversion failed) is sent; this message itself may
immediately require conversion. Part of that conversion will
involve converting the original datagram.
o 或るものが一般的な場合における失敗を引き起こしても、変換は、利用可能なすべての分野を完成するのを試みるべきです。 失敗が起こるとデータグラムを変換することの間にICMPメッセージ(変換は失敗した)が送られることに特に注意してください。 このメッセージ自体はすぐに、変換を必要とするかもしれません。 その変換の一部が、オリジナルのデータグラムを変換することを伴うでしょう。
o Conditions such as overall datagram length too large are not
checked.
o 総合的なデータグラムの長さなどのように大き過ぎる状態はチェックされません。
o The AD and subnet byte assumed in the nested conversion may
not be sensible if the IPv4 address extension option is not
present and the datagram has strayed from the expected AD.
(Not unlikely, given that we know a priori that some error
occured.)
o IPv4アドレス拡大オプションが存在していなくて、データグラムが予想されたADからはぐれたなら、入れ子にされた変換で想定されたADとサブネットバイトは分別がないかもしれません。 (ありそうもなくなくて、それを考えて、私たちは、何らかの誤りがoccuredされたのを先験的に知っています。)
o The conversion must be very sure not to make another
recursive call if the nested datagram is an ICMP message.
(This should not occur, but obviously may.)
o 変換は、入れ子にされたデータグラムがICMPメッセージであるなら別の再帰的呼び出しをしないように非常に確かでなければなりません。 (しかし、これが明らかに起こるべきでない、)であるかもしれない。
o It is probably impossible to generate a correct transport
layer checksum in the nested datagram. The conversion may
prefer to just zero the checksum field. Likewise, validating
the original checksum is pointless.
o 入れ子にされたデータグラムで正しいトランスポート層がチェックサムであると生成するのはたぶん不可能です。 変換は、ただチェックサム分野のゼロを合わせるのを好むかもしれません。 同様に、オリジナルのチェックサムを有効にするのは無意味です。
It may be best in a given implementation to have a separate code path for the nested conversion, that handles these issues out of the optimized usual path.
与えられた実装でそれが入れ子にされた変換のための別々のコード経路を持つために最も良いかもしれない、それは最適化された普通の経路からこれらの問題を扱います。
9. Postscript
9. 追伸
The present version of TCP/IP has been a success partly by accident, for reasons that weren't really designed in. Perhaps the most significant is the low level of network integration required to make it work.
それが本当に設計されなかった理由でTCP/IPの現在のバージョンは偶然に一部成功です。 恐らく最も重要であるのは、働かせるのに必要である低レベルのネットワーク集積です。
Ullmann [Page 33] RFC 1475 TP/IX June 1993
ウルマン[33ページ]RFC1475TP/IX1993年6月
We must be careful to retain the successful ingredients, even where we may be unaware of them. Tread lightly, and use all that we have learned, especially about not changing things that work.
私たちはそれらに気づかなくさえあるかもしれないところでうまくいっている成分を保有するのに慎重であるに違いありません。 慎重に扱ってください、そして、私たちが特に働いているものを変えないことに関して学んだすべてを使用してください。
This document has described a fairly conservative step forward, with clear extensibility for future developments, but without jumping into the abyss.
未来の発展のための明確な伸展性にもかかわらず、深淵までジャンプしないで、このドキュメントはかなり保守的な前進について説明しました。
10. References
10. 参照
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
USC/Information Sciences Institute, August 1980.
[RFC768] ポステル、J.、「ユーザー・データグラム・プロトコル」、STD6、RFC768、科学が1980年8月に設けるUSC/情報。
[RFC791] Postel, J., "Internet Protocol - DARPA Internet Program
Protocol Specification", STD 5, RFC 791, DARPA,
September 1981.
[RFC791] ポステル、J.、「インターネットは議定書を作ります--DARPAインターネットはプロトコル仕様をプログラムする」STD5、RFC791、DARPA、1981年9月。
[RFC792] Postel, J., "Internet Control Message Protocol -
DARPA Internet Program Protocol Specification"
STD 5, RFC 792, USC/Information Sciences Institute,
September 1981.
[RFC792]ポステル、J.、「インターネットはメッセージプロトコルを制御します--DARPAインターネットプログラムプロトコル仕様」というSTD5、RFC792(科学が1981年9月に設けるUSC/情報)。
[RFC793] Postel, J., "Transmission Control Protocol - DARPA
Internet Program Protocol Specification", STD 7, RFC 793,
USC/Information Sciences Institute, September 1981.
[RFC793]ポステル、J.、「転送管理は議定書を作ります--DARPAインターネットプログラムプロトコル仕様」、STD7、RFC793、科学が設けるUSC/情報、1981年9月。
[RFC801] Postel, J., "NCP/TCP Transition Plan", USC/Information
Sciences Institute, November 1981.
[RFC801] ポステル、J.、「NCP/TCP変遷プラン」とUSC/情報科学は、1981年11月に設けます。
[RFC1287] Clark, D., Chapin, L., Cerf, V., Braden, R., and
R. Hobby, "Towards the Future Internet Architecture", RFC
1287, MIT, BBN, CNRI, ISI, UCDavis, December 1991.
[RFC1287] クラークとD.とチェーピンとL.とサーフとV.とブレーデン、R.とR.趣味、「将来のインターネットアーキテクチャ」、RFC1287、MIT、BBN、CNRI、ISI、UCDavis(1991年12月)。
[RFC1323] Jacobson, V., Braden, R, and D. Borman, "TCP Extensions
for High Performance", RFC 1323, LBL, USC/Information
Sciences Institute, Cray Research, May 1992.
[RFC1323]ジェーコブソンとV.とブレーデン、RとD.ボーマン、「高性能のためのTCP拡張子」RFC1323、LBL、科学が設けるUSC/情報(クレイリサーチ)は1992がそうするかもしれません。
[RFC1335] Wang, Z., and J. Crowcroft, A Two-Tier Address Structure
for the Internet: A Solution to the Problem of Address
Space Exhaustion", RFC 1335, University College London,
May 1992.
[RFC1335] ワング、Z.、およびJ.クロウクロフト、2層がインターネットに構造を扱います: 「アドレス空間疲労困憊の問題の解決」、RFC1335、ユニバーシティ・カレッジロンドンは1992がそうするかもしれません。
[RFC1338] Fuller, V., Li, T., Yu, J., and K. Varadhan,
"Supernetting: an Address Assignment and Aggregation
Strategy", RFC 1338, BARRNet, cicso, Merit, OARnet,
June 1992.
[RFC1338] フラー、V.、李、T.、ユー、J.、およびK.Varadhan、「スーパーネッティング:」 Merit、OARnet、「Address AssignmentとAggregation Strategy」(RFC1338、BARRNet)がcicsoする、6月1992日
Ullmann [Page 34] RFC 1475 TP/IX June 1993
ウルマン[34ページ]RFC1475TP/IX1993年6月
[RFC1347] Callon, R., "TCP and UDP with Bigger Addresses (TUBA),
A Simple Proposal for Internet Addressing and Routing",
RFC 1347, DEC, June 1992.
[RFC1347]Callon、R.、「より大きいのがあるTCPとUDPは(tuba)、インターネットアドレシングとルート設定のための簡単な提案を扱います」、RFC1347、1992年12月、6月。
[RFC1476] Ullmann, R., "RAP: Internet Route Access Protocol",
RFC 1476, Process Software Corporation, June 1993.
[RFC1476] ウルマン、R.は「以下を叩きます」。 「インターネットルートアクセス・プロトコル」、RFC1476は1993年6月にソフトウェア社を処理します。
[RFC1379] Braden, R., "Extending TCP for Transactions -- Concepts",
RFC 1379, USC/Information Sciences Institute,
November 1992.
[RFC1379] ブレーデン、「トランザクション--概念のためにTCPを広げている」RFC1379、USC/情報科学が1992年11月に設けるR.。
11. Security Considerations
11. セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
12. Author's Address
12. 作者のアドレス
Robert Ullmann Process Software Corporation 959 Concord Street Framingham, MA 01701 USA
ロバートウルマンプロセスソフトウェア社959の一致通りMA01701フレイミングハム(米国)
Phone: +1 508 879 6994 x226 Email: Ariel@Process.COM
以下に電話をしてください。 +1 6994年の508 879x226メール: Ariel@Process.COM
Ullmann [Page 35]
ウルマン[35ページ]
一覧
スポンサーリンク
