RFC1707 日本語訳
1707 CATNIP: Common Architecture for the Internet. M. McGovern, R.Ullmann. October 1994. (Format: TXT=37568 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group: M. McGovern
Request for Comments: 1707 Sunspot Graphics
Category: Informational R. Ullmann
Lotus Development Corporation
October 1994
作業部会をネットワークでつないでください: M。 コメントを求めるマクガヴァンRequest: 1707年の太陽黒点グラフィックスカテゴリ: 情報のR.ウルマンLotus Development Corporation1994年10月
CATNIP: Common Architecture for the Internet
キャットニップ: インターネットへの一般的なアーキテクチャ
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 このメモはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Abstract
要約
This document was submitted to the IETF IPng area in response to RFC 1550 Publication of this document does not imply acceptance by the IPng area of any ideas expressed within. Comments should be submitted to the big-internet@munnari.oz.au mailing list.
RFCに対応したこのドキュメントの1550Publicationがどんな考えの領域も急送したIPngによる承認を含意しないIETF IPng領域にこのドキュメントを提出しました。 big-internet@munnari.oz.au メーリングリストにコメントを提出するべきです。
Executive Summary
要約
This paper describes a common architecture for the network layer protocol. The Common Architecture for Next Generation Internet Protocol (CATNIP) provides a compressed form of the existing network layer protocols. Each compression is defined so that the resulting network protocol data units are identical in format. The fixed part of the compressed format is 16 bytes in length, and may often be the only part transmitted on the subnetwork.
この論文はネットワーク層プロトコルのために一般的なアーキテクチャについて説明します。 Next Generationインターネットプロトコル(CATNIP)のためのCommon Architectureは既存のネットワーク層プロトコルの圧縮形を提供します。 各圧縮が定義されるので、結果として起こるネットワーク・プロトコルデータ単位は形式が同じです。 圧縮形式の固定部分は、長さ16バイトであり、しばしばサブネットワークの上で伝えられた唯一の部分であるかもしれません。
With some attention paid to details, it is possible for a transport layer protocol (such as TCP) to operate properly with one end system using one network layer (e.g. IP version 4) and the other using some other network protocol, such as CLNP. Using the CATNIP definitions, all the existing transport layer protocols used on connectionless network services will operate over any existing network layer protocol.
何らかの注意を詳細に向けていて、片端システムが1つのネットワーク層(例えば、IPバージョン4)を使用していて、もう片方がある他のネットワーク・プロトコルを使用している状態でトランスポート層プロトコル(TCPなどの)が適切に作動するのは、可能です、CLNPなどのように。 CATNIP定義を使用して、コネクションレスなネットワーク・サービスのときに使用されたすべての既存のトランスポート層プロトコルがどんな既存のネットワーク層プロトコルの上でも作動するでしょう。
The CATNIP uses cache handles to provide both rapid identification of the next hop in high performance routing as well as abbreviation of the network header by permitting the addresses to be omitted when a valid cache handle is available. The fixed part of the network layer header carries the cache handles.
CATNIPは、有効なキャッシュハンドルが利用可能であるときにアドレスが省略されることを許可することによって高性能ルーティングにおける、次のホップの急速な識別とネットワークヘッダーの略語の両方を提供するのにキャッシュハンドルを使用します。 ネットワーク層ヘッダーの固定一部がキャッシュハンドルを運びます。
McGovern & Ullmann [Page 1] RFC 1707 CATNIP October 1994
マクガヴァンとウルマン[1ページ]RFC1707キャットニップ1994年10月
The cache handles are either provided by feedback from the downstream router in response to offered traffic, or explicitly provided as part of the establishment of a circuit or flow through the network. When used for flows, the handle is the locally significant flow identifier.
フィードバックでトラフィックを提供するか、または回路か流れの設立の一部として明らかに提供していることに対応した川下のルータからネットワークまでキャッシュハンドルを提供します。 流れに使用されると、ハンドルは局所的に重要な流れ識別子です。
When used for circuits, the handle is the layer 3 peer-to-peer logical channel identifier, and permits a full implementation of network-layer connection-oriented service if the routers along the path provide sufficient features. At the same time, the packet format of the connectionless service is retained, and hop by hop fully addressed datagrams can be used at the same time. Any intermediate model between the connection oriented and the connectionless service can thus be provided over cooperating routers.
回路に使用されると、ハンドルは、層の3ピアツーピア論理チャネル識別子であり、経路に沿ったルータが十分な特徴を提供するなら、ネットワーク層コネクション型サービスの完全な実施を可能にします。 同時に、コネクションレス型サービスのパケット・フォーマットを保有します、そして、ホップごとに、同時に、使用できます。 その結果、適応する接続とコネクションレス型サービスの間のどんな中間的モデルも協力ルータの上に提供できます。
CATNIP Objectives
キャットニップ目的
The first objective of the CATNIP is a practical recognition of the existing state of internetworking, and an understanding that any approach must encompass the entire problem. While it is common in the IP Internet to dismiss the ISO with various amusing phrases, it is hardly realistic. As the Internet moves into the realm of providing real commercial infrastructure, for telephone, cable television, and the myriad other mundane uses, compliance with international standards is an imperative.
CATNIPの最初の目的は、インターネットワーキングの現状の実用的な認識と、どんなアプローチも全体の問題を包含しなければならないという理解です。 様々なおもしろい句でISOを棄却するのがIPインターネットで一般的ですが、それはほとんど現実的ではありません。 インターネットが電話、ケーブルテレビ、および他の無数の世俗的な用途に全く商業のインフラストラクチャを供給する分野に移行するとき、世界規格への承諾は命令です。
The argument that the IETF need not (or should not) follow existing ISO standards will not hold. The ISO is the legal standards organization for the planet. Every other industry develops and follows ISO standards. There is (no longer) anything special about computer software or data networking.
または、IETFがそうする必要はない議論、()、ISO規格が保持しない存在に続くべきであってください。 ISOは惑星のための法的基準組織です。 他のあらゆる産業が、ISO規格を開発して、続きます。 (もう、)コンピュータ・ソフトウェアかデータネットワークに関して特別なものは何もありません。
ISO convergence is both necessary and sufficient to gain international acceptance and deployment of IPng. Non-convergence will effectively preclude deployment.
ISO集合は、必要であって、かつIPngの国際的な承認と展開を獲得するために十分です。 事実上、非集合は展開を排除するでしょう。
The CATNIP integrates CLNP, IP, and IPX. The CATNIP design provides for any of the transport layer protocols in use, for example TP4, CLTP, TCP, UDP, IPX and SPX to run over any of the network layer protocol formats: CLNP, IP (version 4), IPX, and the CATNIP.
CATNIPはCLNP、IP、およびIPXを統合します。 CATNIPデザインは使用中のトランスポート層プロトコルのどれかに備えます、例えば、ネットワーク層のどれかをひくTP4、CLTP、TCP、UDP、IPX、およびSPXは形式について議定書の中で述べます: CLNP、IP(バージョン4)、IPX、およびキャットニップ。
Incremental Infrastructure Deployment
増加のインフラストラクチャ展開
The best use of the CATNIP is to begin to build a common Internet infrastructure. The routers and other components of the common system are able to use a single consistent addressing method, and common terms of reference for other aspects of the system.
CATNIPの最善の利用は一般的なインターネット基盤を築き上げ始めることです。 一般的なシステムのルータと他の部品はシステムの他の局面にただ一つの一貫したアドレス指定法、および一般的な委任事項を使用できます。
McGovern & Ullmann [Page 2] RFC 1707 CATNIP October 1994
マクガヴァンとウルマン[2ページ]RFC1707キャットニップ1994年10月
The CATNIP is designed to be incrementally deployable in the strong sense: you can plop a CATNIP system down in place of any existing network component and continue to operate normally with no reconfiguration. (Note: not "just a little". None at all. The number of "little changes" suggested by some proposals, and the utterly enormous amount of documentation, training, and administrative effort then required, astounds the present authors.) The vendors do all of the work.
CATNIPは強い意味で増加して配布可能することになるように設計されています: あなたは、どんな既存のネットワーク要素に代わってCATNIPシステムダウンをどぶんと落として、通常、再構成なしで作動し続けることができます。 以下に「ちょうど少しどんな」も注意しないでください。(次に、訓練していて、管理の取り組みは. すべての数の「小さい変化」のNoneがいくつかの提案で示して、全くドキュメンテーションの巨額が現在の作者を驚かせるのを必要としました) ベンダーは仕事のすべてをします。
There are also no external requirements; no "border routers", no requirement that administrators apply specific restrictions to their network designs, define special tables, or add things to the DNS. When the end users and administrators fully understand the combined system, they will want to operate differently, but in no case will they be forced. Not even in small ways. Networks and end user organizations operate under sufficient constraints on deployment of systems anyway; they do not need a new network architecture adding to the difficulty.
また、どんな外部の要件もありません。 「境界ルータ」がない、管理者がそれらのネットワークデザインに特定の制限を適用するというどんな要件も、特別なテーブルを定義もしませんし、DNSに事態を加えもしません。 いつエンドユーザと管理者は混合構造を完全に理解していますが、異なって作動したくなるでしょうが、彼らは決して、強制されないだろうか。 わずかな方法で同等ではありません。 ネットワークとエンドユーザ組織は十分な規制でシステムの展開をとにかく作動させます。 彼らは困難に加える新しいネットワークアーキテクチャを必要としません。
Typically deployment will occur as part of normal upgrade revisions of software, and due to the "swamping" of the existing base as the network grows. (When the Internet grows by a factor of 5, at least 80% will then be "new" systems.) The users of the network may then take advantage of the new capabilities. Some of the performance improvements will be automatic, others may require some administrative understanding to get to the best performance level.
展開は、通常、ソフトウェアの通常のアップグレード改正の一部として起こって、ネットワークとしての存立基盤の「湿地帯」のため成長します。 (インターネットが5、少なくとも80の要素で発展するとき、そして%は「新しい」システムになるでしょう。) そして、ネットワークのユーザは新しい能力を利用するかもしれません。 性能改良のいくつかが自動になる、他のものは最も良い性能レベルを始めるために何らかの管理理解を必要とするかもしれません。
The CATNIP definitions provide stateless translation of network datagrams to and from CATNIP and, by implication, directly between the other network layer protocols. A CATNIP-capable system implementing the full set of definitions can interoperate with any existing protocol. Various subsets of the full capability may be provided by some vendors.
CATNIP定義はネットワーク層プロトコルと、そして、CATNIPと含意による他のネットワーク層プロトコルの直接間にネットワークデータグラムの状態がない翻訳を供給します。 定義のフルセットを実装するCATNIPできるシステムはどんな既存のプロトコルでも共同利用できます。 完全な能力の様々な部分集合はいくつかのベンダーによって提供されるかもしれません。
No Address Translation
アドレス変換がありません。
Note that there is no "address translation" in the CATNIP specification. (While it may seem odd to state a negative objective, this is worth saying as people seem to assume the opposite.) There are no "mapping tables", no magic ways of digging translations out of the DNS or X.500, no routers looking up translations or asking other systems for them.
CATNIP仕様には「アドレス変換」が全くないことに注意してください。 (否定的目的を述べるのが変に思えるかもしれませんが、これは言う人々が、正反対を仮定するように思えるように価値があります。) 「マッピングテーブル」がない、DNSかX.500から翻訳を掘る魔法の方法がない、翻訳を調べるルータまたは他のシステムに彼らを求めるのがありません。
Addresses are modified with a simple algorithmic mapping, a mapping that is no more than using specific prefixes for IP and IPX addresses. Not a large set of prefixes; one prefix. The entire existing IP version 4 network is mapped with one prefix and the IPX global network with one other prefix. (The IP mapping does provide
アドレスは簡単なアルゴリズムのマッピング(IPとIPXアドレスに特定の接頭語を使用しているだけであるマッピング)で変更されます。 大きいセットの接頭語でない。 1つの接頭語。 全体の既存のIPバージョン4ネットワークは1つの接頭語とIPX世界的なネットワークと共に他の1つの接頭語で写像されます。 (IPマッピングは提供されます。
McGovern & Ullmann [Page 3] RFC 1707 CATNIP October 1994
マクガヴァンとウルマン[3ページ]RFC1707キャットニップ1994年10月
for future assignment of other IANA/IPv4 domains that are disjoint from the existing one.)
他のIANA/IPv4ドメインの将来の課題には、既存のものから、ばらばらになってください。)
This means that there is no immediate effect on addresses embedded in higher level protocols.
これは、より高い平らなプロトコルに埋め込まれたアドレスへのどんな即座の効果もないことを意味します。
Higher level protocols not using the full form (those native to IP and IPX) will eventually be extended to use the full addressing to extend their usability over all of the network layers.
完全形(IPとIPXのネイティブであるそれら)を使用しないより高い平らなプロトコルは、結局、ネットワーク層のすべて上でそれらのユーザビリティを広げるのに完全なアドレシングを使用するために広げられるでしょう。
No Legacy Systems
レガシーシステムがありません。
The CATNIP leaves no systems behind: with no reconfiguration, any system presently capable of IP, CLNP, or IPX retains at least the connectivity it has now. With some administrative changes (such as assigning IPX domain addresses to some CLNP hosts for example) on other systems, unmodified systems may gain significant connectivity. IPX systems with registered network numbers may gain the most.
CATNIPはシステムを全く後に残しません: 再構成がなければ、現在IP、CLNP、またはIPXができるどんなシステムも少なくともそれが現在持っている接続性を保有します。 他のシステムの上にいくつかの管理変化(例えば、何人かのCLNPホストへのドメインアドレスをIPXに割り当てなどなどの)がある状態で、変更されていないシステムは重要な接続性を獲得するかもしれません。 登録されたネットワーク・ナンバーがあるIPXシステムは最も獲得されるかもしれません。
Limited Scope
株式会社の範囲
The CATNIP defines a common network layer packet format and basic architecture. It intentionally does not specify ES-IS methods, routing, naming systems, autoconfiguration and other subjects not part of the core Internet wide architecture. The related problems and their (many) solutions are not within the scope of the specification of the basic common network layer.
CATNIPは一般的なネットワーク層パケット・フォーマットと基本的なアーキテクチャを定義します。 それが故意に指定しない、ES存在、メソッド、ルーティング(システム、自動構成、および他の対象が分けないコアのインターネットの広いアーキテクチャの命名) 基本的な一般的なネットワーク層の仕様の範囲の中に関連する問題とそれらの(多く)のソリューションがありません。
Existing Addresses and Network Numbers
既存のアドレスとネットワーク・ナンバー
The Internet's version 4 numbering system has proven to be very flexible, (mostly) expandable, and simple. In short: it works. However, there are two problems. Neither was considered serious when the CATNIP was first developed in 1988 and 1989, but both are now of major concern:
インターネットのバージョン4付番システムは非常にフレキシブルで、(ほとんど)拡張可能で、簡単であると判明しました。 要するに: それは働いています。 しかしながら、2つの問題があります。CATNIPが1988年と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ビットの限界はますます多くの深刻化を引き起こします。
Another major addressing system used in open internetworking is the OSI method of specifying Network Service Access Points (NSAPs). The NSAP consists of an authority and format identifier, a number
開いているインターネットワーキングに使用される別の主要なアドレス指定方式はNetwork Service Access Points(NSAPs)を指定するOSIメソッドです。 NSAPは権威と形式ID、数から成ります。
McGovern & Ullmann [Page 4] RFC 1707 CATNIP October 1994
マクガヴァンとウルマン[4ページ]RFC1707キャットニップ1994年10月
assigned to that authority, an address assigned by that authority, and a selector identifying the next layer (transport layer) protocol. This is actually a general multi-level hierarchy, often obscured by the details of specific profiles. (For example, CLNP doesn't specify 20 octet NSAPs, it allows any length. But various GOSIPs profile the NSAP as 20 octets, and IS-IS makes specific assumptions about the last 1-8 octets. And so on.)
その権威、その権威によって割り当てられたアドレス、および次の層(トランスポート層)のプロトコルを特定するセレクタに割り当てられます。 これは実際にしばしば特定のプロフィールの細部によってあいまいにされた一般的なマルチレベル階層構造です。 (例えば、CLNPはそれでどんな長さにも20八重奏NSAPsを指定できません。 そして、しかし、様々なGOSIPsが20の八重奏としてNSAPをプロフィールである、-、最後の1-8に関する特定の仮定を八重奏にします。 など。)
The NSAP does not directly correspond to an IP address, as the selector in IP is separate from the address. The concept that does correspond is the NSAP less the selector, called the Network Entity Title or NET. (An unfortunate acronym, but one we will use to avoid repeating the full term.) The usual definition of NET is an NSAP with the selector set to 0; the NET used here omits the 0 selector.
IPにおけるセレクタがアドレスから別々であるときに、NSAPは直接IPアドレスに対応していません。 対応する概念は、よりNSAP以下です。Network Entity TitleかNETと呼ばれるセレクタ。 (不幸な頭文字語、しかし、私たちが満期を繰り返すのを避けるのに使用するつもりである1つ。) NETの普通の定義は0に設定されたセレクタがあるNSAPです。 ここで使用されたNETは0セレクタを省略します。
There is also a network numbering system used by IPX, a product of Novell, Inc. (referred to from here on as Novell) and other vendors making compatible software. While IPX is not yet well connected into a global network, it has a larger installed base than either of the other network layers.
また、IPXによって使用されたネットワーク付番システムがあります、ノベルInc.(これからノベルに言及される)と他のベンダーの製品がコンパチブルソフトウェアを作って。 IPXはまだ世界的なネットワークによく接続されていませんが、それには、他のネットワーク層のどちらかより大きいインストールされたベースがあります。
Network Layer Address
ネットワーク層アドレス
The network layer address looks like:
ネットワーク層アドレスに似ています:
+----------+----------+---------------+---------------+
| length | AFI | IDI ... | DSP ... |
+----------+----------+---------------+---------------+
+----------+----------+---------------+---------------+ | 長さ| AFI| イディ… | DSP… | +----------+----------+---------------+---------------+
The fields are named in the usual OSI terminology although that leads to an oversupply of acronyms. Here are more detailed descriptions of each field:
それは頭文字語の供給過剰に通じますが、分野は普通のOSI用語で命名されます。ここに、それぞれの分野の、より詳細な記述があります:
length: the number of bytes (octets) in the remainder of the
address.
長さ: アドレスの残りにおけるバイト数(八重奏)。
AFI: the Authority and Format Identifier. A single byte
value, from a set of well-known values registered by
ISO, that determines the semantics of the IDI field
AFI: 権威と形式ID。 ISOによって示された1セットのよく知られる値からのIDI分野の意味論を決定するただ一つのバイト値
IDI: the Initial Domain Identifier, a number assigned by the
authority named by the AFI, formatted according to the
semantics implied by the AFI, that determines the
authority for the remainder of the address.
イディ: Initial Domain Identifier(アドレスの残りのために権威を決定するAFIによって含意された意味論によると、フォーマットされたAFIによって指定された権威によって割り当てられた数)。
DSP: Domain Specific Part, an address assigned by the
authority identified by the value of the IDI.
DSP: ドメインSpecific Part、IDIの値によって特定された権威によって割り当てられたアドレス。
McGovern & Ullmann [Page 5] RFC 1707 CATNIP October 1994
マクガヴァンとウルマン[5ページ]RFC1707キャットニップ1994年10月
Note that there are several levels of authority. ISO, for example, identifies (with the AFI) a set of numbering authorities (like X.121, the numbering plan for the PSPDN, or E.164, the numbering plan for the telephone system). Each authority numbers a set of organizations or individuals or other entities. (For example, E.164 assigns 16172477959 to me as a telephone subscriber.)
権威のいくつかのレベルがあることに注意してください。 例えば、ISOは1セットの付番当局(X.121、PSPDNのための付番プラン、またはE.164、電話のための付番プランのような)を特定します(AFIと共に)。 各権威は組織、個人または他の実体の1セットに付番します。 (例えば、E.164は電話加入者として16172477959を私に割り当てます。)
The entity then is the authority for the remainder of the address. I can do what I please with the addresses starting with (AFI=E.164) (IDI=16172477959). Note that this is a delegation of authority, and not an embedding of a data-link address (the telephone number) in a network layer address. The actual routing of the network layer address has nothing to do with the authority numbering.
そして、実体はアドレスの残りのための権威です。 私はアドレスが(AFI=E.164)(IDI=16172477959)から始まっていて自分が喜ばせることができます。 これがデータ・リンク・アドレス(電話番号)のネットワーク層アドレスへの埋め込みではなく、権限の委任であることに注意してください。 ネットワーク層アドレスの実際のルーティングは権威付番と関係ありません。
The domain-specific part is variable length, and can be allocated in whatever way the authority identified by the AFI+IDI desires.
ドメイン特有の部分を可変長であり、権威がAFI+IDI願望で特定したどんな方法でも割り当てることができます。
Network Layer Datagram
ネットワーク層データグラム
The common architecture format for network layer datagrams is described below. The design is a balance between use on high performance networks and routers, and a desire to minimize the number of bits in the fixed header. Using the current state of processor technology as a reference, the fixed header is all loaded into CPU registers on the first memory cycle, and it all fits within the operation bandwidth. The header leaves the remaining data aligned on the header size (128 bits); with 64 bit addresses present and no options it leaves the transport header 256 bit aligned.
ネットワーク層データグラムのための一般的なアーキテクチャ形式は以下で説明されます。 デザインは、高性能ネットワークにおける使用とルータの間のバランスと、固定ヘッダーのビットの数を最小にする願望です。 参照としてプロセッサ技術の現状を使用して、固定ヘッダーは最初のメモリサイクルに関するCPUレジスタにすべて積み込まれます、そして、それはすべて、操作帯域幅の中で合います。 ヘッダーは残っているデータをヘッダーサイズ(128ビット)で並べられたままにします。 アドレスが寄贈する64ビットにもかかわらず、それが輸送ヘッダーを残すどんなオプションにはも、256ビットは並びませんでした。
On very slow and low performance networks, the fixed header is still fairly small, and could be further compressed by methods similar to those used with IP version 4 on links that consider every bit precious. In between, it fits nicely into ATM cells and radio packets, leaving sufficient space for the transport header and application data.
非常に遅くて低い性能ネットワークに、固定ヘッダーは、まだかなり小さく、あらゆるビットが貴重であると考えるリンクの上のIPバージョン4と共に使用されるものと同様のメソッドでさらに圧縮できるでしょう。 中間で、ATMセルとラジオパケットにしっくり合います、輸送ヘッダーとアプリケーションのための十分なスペースをデータに出て。
McGovern & Ullmann [Page 6] RFC 1707 CATNIP October 1994
マクガヴァンとウルマン[6ページ]RFC1707キャットニップ1994年10月
+---------------+---------------+-+-+-+-+-+-+-+-+---------------+
| NLPID (70) | Header Size |D|S|R|M|E| MBZ | Time to Live |
+---------------+---------------+-+-+-+-+-+-+-+-+---------------+
| Forward Cache Identifier |
+---------------------------------------------------------------+
| Datagram Length |
+---------------------------------------------------------------+
| Transport Protocol | Checksum |
+---------------------------------------------------------------+
| Destination Address ... |
+---------------------------------------------------------------+
| Source Address ... |
+---------------------------------------------------------------+
| Options ... |
+---------------------------------------------------------------+
+---------------+---------------+-+-+-+-+-+-+-+-+---------------+ | NLPID(70)| ヘッダーサイズ|D|S|R|M|E| MBZ| 生きる時間| +---------------+---------------+-+-+-+-+-+-+-+-+---------------+ | 前進のキャッシュ識別子| +---------------------------------------------------------------+ | データグラムの長さ| +---------------------------------------------------------------+ | トランスポート・プロトコル| チェックサム| +---------------------------------------------------------------+ | 送付先アドレス… | +---------------------------------------------------------------+ | ソースアドレス… | +---------------------------------------------------------------+ | オプション… | +---------------------------------------------------------------+
NLPID: The first byte (the network layer protocol identifier in OSI)
is an 8 bit constant 70 (hex). This corresponds to Internet
Version 7.
NLPID: 最初のバイト(OSIのネットワーク層プロトコル識別子)は8ビット定数70です(魔法をかけます)。 これはインターネットバージョン7に対応しています。
Header Length: The header length is a 8-bit count of the number of
32-bit words in the header. This allows the header to
be up to 1020 bytes in length.
ヘッダ長: ヘッダ長はヘッダーの32ビットの単語の数の8ビットのカウントです。 これで、ヘッダーは長さ1020バイトができます。
Flags: This byte is a small set of flags determining the datagram
header format and the processing semantics. The last three bits
are reserved, and must be set to zero. (Note that the
corresponding bits in CLNP version 1 are 001, since this byte
is the version field. This may be useful.)
旗: このバイトはデータグラムヘッダー形式と処理意味論を決定する小さいセットの旗です。 最後の3ビットを予約されていて、ゼロに設定しなければなりません。 (このバイトがバージョン分野であるので、CLNPバージョン1の対応するビットが001であることに注意してください。 これは役に立つかもしれません。)
Destination Address Omitted: When the destination address omitted
(DAO) flag is zero, the destination address is present as shown
in the datagram format diagram. When a datagram is sent with
an FCI that identifies the destination and the DAO flag is
set, the address does not appear in the datagram.
送付先アドレスは省略しました: 送付先アドレスが(DAO)を省略したとき、旗がゼロである、送付先アドレスはデータグラム形式ダイヤグラムで示されるように存在しています。 目的地を特定するFCIと共にデータグラムを送って、DAO旗を設定するとき、アドレスはデータグラムに現れません。
Source Address Omitted: The source address omitted (SAO) flag is zero
when the source address is present in the datagram. When
datagram is sent with an FCI that identifies the source and the
SAO flag is set, the source address is omitted from the
datagram.
ソースアドレスは省略しました: ソースアドレスがデータグラムに存在しているとき、ソースアドレスの省略された(SAO)旗はゼロです。 ソースを特定するFCIと共にデータグラムを送って、SAO旗を設定するとき、データグラムからソースアドレスを省略します。
Report Fragmentation Done: When this bit (RFD) is set, an intermediate
router that fragments the datagram (because it is larger than
the next subnetwork MTU) should report the event with an ICMP
Datagram Too Big message. (Unlike IP version 4, which uses DF
for MTU discovery, the RFD flag allows the fragmented datagram
断片化が行われると報告してください: このビット(RFD)が設定されるとき、データグラム(それが次のサブネットワークMTUより大きいので)を断片化する中間的ルータはICMPデータグラムToo Bigメッセージで出来事を報告するべきです。 (IPバージョン4と異なって、RFD旗は断片化しているデータグラムを許容します。バージョンはMTU発見にDFを使用します。
McGovern & Ullmann [Page 7] RFC 1707 CATNIP October 1994
マクガヴァンとウルマン[7ページ]RFC1707キャットニップ1994年10月
to be delivered.)
渡すために。)
Mandatory Router Option: The mandatory router option (MRO) flag
indicates that routers forwarding the datagram must look at the
network header options. If not set, an intermediate router
should not look at the header options. (But it may anyway;
this is a necessary consequence of transparent network layer
translation, which may occur anywhere.)
義務的なルータオプション: 義務的なルータオプション(MRO)旗は、データグラムを進めるルータがネットワークヘッダー選択を見なければならないのを示します。 設定されないなら、中間的ルータはヘッダー選択を見るべきではありません。 (しかし、とにかくそうするかもしれません; これはわかりやすいネットワーク層翻訳の必要な結果です。)(翻訳はどこでも現れるかもしれません)。
The destination host, or an intermediate router doing
translation, must look at the header options regardless of
the setting of the MRO flag.
あて先ホスト、または翻訳をする中間的ルータがMRO旗の設定にかかわらずヘッダー選択を見なければなりません。
A router doing fragmentation will normally only use the F
flag in options to determine whether options should be copied
within the fragmentation code path. (It might also recognize
and elide null options.) If the MRO flag is not set, the router
may not act on an option even though it copies it properly
during fragmentation.
通常、断片化をするルータは、オプションが断片化コード経路の中にコピーされるべきであるかどうか決定するのにオプションにF旗を使用するだけでしょう。 (また、それは、ヌルオプションを認識して、削除するかもしれません。) MRO旗が設定されないなら、断片化の間適切にそれをコピーしますが、ルータはオプションに影響しないかもしれません。
If there are no options present, MRO should always be zero, so
that routers can follow the no-option profile path in their
implementation. (Remember that the presence of options cannot
be divided from the header length, since the addresses are
variable length.)
どんな存在しているオプションもなければ、いつもMROはゼロであるべきです、ルータが彼らの実現におけるオプションがないプロフィール経路に続くことができるように。 (アドレスが可変長であるので、ヘッダ長からオプションの存在を分割できなかったのを覚えていてください。)
Error Report Suppression: The ERS flag is set to suppress the sending
of error reports by any system (whether host or router)
receiving or forwarding the datagram. The system may log the
error, increment network management counters, and take any
similar action, but ICMP error messages or CNLP error reports
must not be sent.
エラー・レポート抑圧: ERS旗はどんなシステム(ホストかルータであることにかかわらず)でもデータグラムを受けるか、または進めながらエラー・レポートの発信を抑圧するセットです。 システムは、誤りを登録して、ネットワークマネージメントカウンタを増加して、どんな同様の行動も取るかもしれませんが、ICMPエラーメッセージかCNLPエラー・レポートを送ってはいけません。
The ERS flag is normally set on ICMP messages and other network
layer error reports. It does not suppress the normal response
to ICMP queries or similar network layer queries (CNLP echo
request).
通常、ERS旗はICMPメッセージと他のネットワーク層誤りレポートに設定されます。 それはICMP質問か同様のネットワーク層質問(CNLPエコー要求)への通常の応答を抑圧しません。
If both the RFD and ERS flags are set, the fragmentation report
is sent. (This definition allows a larger range of
possibilities than simply over-riding the RFD flag would; a
sender not desiring this behavior can see to it that RFD is
clear.)
RFDとERS旗の両方を設定するなら、断片化レポートを送ります。 (この定義は単にRFD旗をくつがえすのがそうするだろうより大きい可能性として考えられる範囲を許容します; この振舞いを望んでいない送付者は、RFDが明確であるように取り計らうことができます。)
Time To Live: The time to live is a 8-bit count, nominally in seconds.
Each hop is required to decrement TTL by at least one. A hop
that holds a datagram for an unusual amount of time (more than
2 seconds, a typical example being a wait for a subnetwork
生きる時間: 生きるのが、8ビットである時に、秒に名目上は数えてください。 各ホップが、TTLを少なくとも1つ減少させるのに必要です。 珍しい時間データグラムを維持するホップ、(2秒以上、サブネットワークのための待ちである典型的な例
McGovern & Ullmann [Page 8] RFC 1707 CATNIP October 1994
マクガヴァンとウルマン[8ページ]RFC1707キャットニップ1994年10月
connection establishment) should subtract the entire waiting
time in seconds (rounded upward) from the TTL.
コネクション確立) 秒(上向きに、一周する)にTTLから全体の待ち時間を引き算するべきです。
Forward Cache Identifier: Each datagram carries a 32 bit field, called
"forward cache identifier", that is updated (if the information
is available) at each hop. This field's value is derived from
ICMP messages sent back by the next hop router, a routing
protocol (e.g., RAP), or some other method. The FCI 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, circuits, and mobile
host tunnels. If an FCI is not available, this field must be
zero, the SAO and DAO flags must be clear, and both destination
and source addresses must appear in the datagram.
キャッシュ識別子を転送してください: 各データグラムは各ホップでアップデートされる(情報が利用可能であるなら)「前進のキャッシュ識別子」と呼ばれる32ビットの野原を運びます。 これは次のホップルータ、ルーティング・プロトコル(例えば、RAP)、またはある他の方法で返送されたICMPメッセージから得られますフィールドのものが、評価する。 FCIは、連続したルータの間で可能であるところに知識を保存することによってルーティング決定を速めるのに使用されます。 また、データグラムに予約された流れ、サーキット、およびモバイルホストトンネルの範囲内にとどまらせるのにそれを使用できます。 FCIが利用可能でないなら、この分野はゼロであるに違いありません、そして、SAOとDAO旗は明確であるに違いありません、そして、目的地とソースアドレスの両方がデータグラムに現れなければなりません。
Datagram Length: The 32-bit length of the entire datagram in octets.
A datagram can therefore be up to 4294967295 bytes in overall
length. Particular networks normally impose lower limits.
データグラムの長さ: 八重奏における、全体のデータグラムの32ビットの長さ。 したがって、データグラムは全長が最大4294967295バイトであるかもしれません。 通常、特定のネットワークは下限を課します。
Transport Protocol: The transport layer protocol. For example, TCP is
6.
プロトコルを輸送してください: トランスポート層プロトコル。 例えば、TCPは6歳です。
Checksum: The checksum is a 16-bit checksum of the entire header,
using the familiar algorithm used in IP version 4.
チェックサム: IPバージョン4で使用される身近なアルゴリズムを使用して、チェックサムは全体のヘッダーの16ビットのチェックサムです。
Destination: The destination address, a count byte followed by the
destination NSAP with the zero selector omitted. This field is
present only if the DAO flag is zero. If the count field is not
3 modulo 4 (the destination is not an integral multiple of
32-bit words) zero bytes are added to pad to the next multiple
of 32 bits. These pad bytes are not required to be ignored:
routers may rely on them being zero.
目的地: 送付先アドレスであり、カウントバイトはセレクタが省略したゼロと共に目的地NSAPのそばで続きました。 この分野はDAO旗がゼロである場合にだけ存在しています。 カウント分野が法4(目的地は32ビットの単語の不可欠の倍数ではありません)が合っているゼロ3でないなら、バイトは、32ビットの次の倍数にそっと歩くために加えられます。 これらのパッドバイトは無視されるのに必要ではありません: ルータは、ゼロであるのでそれらを当てにするかもしれません。
Source: The source address, in the same format as the destination.
Present only if the SAO flag is zero. The source is padded in
the same way as destination to arrive at a 32-bit boundary.
ソース: 目的地と同じ形式におけるソースアドレス。 SAOが弛む場合にだけ、プレゼントはゼロです。 目的地と同様に、ソースは、32ビットの境界に到着するように水増しされます。
Options: Options may follow. They are variable length, and always
32-bit aligned. If the MRO flag in the header is not set,
routers will usually not look at or take action on any option,
regardless of the setting of the class field.
オプション: オプションは続くかもしれません。 それらは可変長です、そして、いつも32ビットは並びました。 ヘッダーのMRO旗が設定されないと、ルータは、どんなオプションも通常、見ないか、または実行するでしょう、類体の設定にかかわらず。
Multicasting
マルチキャスティング
The multicast-enable option permits multicast forwarding of the CATNIP datagram on subnetworks that directly support media layer multicasting. This is a vanishing species, even in 10 Mbps Ethernet, given the increasing prevalence of switching hubs. It also (perhaps
直接メディア層のマルチキャスティングを支持するサブネットワークにおけるCATNIPデータグラムのオプション許可証マルチキャスト推進をマルチキャストで可能にしてください。 スイッチング・ハブの増加する普及を考えて、これは10のMbpsイーサネットでさえ消え失せている種です。 それ、も(恐らく。
McGovern & Ullmann [Page 9] RFC 1707 CATNIP October 1994
マクガヴァンとウルマン[9ページ]RFC1707キャットニップ1994年10月
more usefully) permits a router to forward the datagram on multiple paths when a multicast routing algorithm has established such paths. There is no option data.
より有効に)、マルチキャストルーティング・アルゴリズムがそのような経路を確立したとき、ルータが複数の経路のデータグラムを進めることを許可します。 オプションデータが全くありません。
Note that there is no special address space for multicasting in the CATNIP. Multicast destination addresses can be allocated anywhere by any administration or authority. This supports a number of differing models of addressing. It does require that the transport layer protocol know that the destination is multicast; this is desirable in any case. (For example, the transport will probably want to set the ERS flag.)
マルチキャスティングのためのどんな特別なアドレス空間もCATNIPにないことに注意してください。 どんな管理や権威もマルチキャスト送付先アドレスをどこでも割り当てることができます。 これはアドレシングの多くの異なったモデルをサポートします。 それは、トランスポート層プロトコルが、目的地がマルチキャストであることを知っているのを必要とします。 どのような場合でも、これは望ましいです。 (例えば、輸送はたぶんERS旗を設定したくなるでしょう。)
On an IEEE 802.x (ISO 8802.x) type media, the last 23 bits of the address (not including the 0 selector) are used in combination with the multicast group address assigned to the Internet to form the media address when forwarding a datagram with the multicast enable option from a router to an attached network provided that the datagram was not received on that network with either multicast or broadcast media addressing. A host may send a multicast datagram either to the media multicast address (the IP catenet model,) or media unicast to a router which is expected to repeat it to the multicast address within the entire level I area or to repeat copies to the appropriate end systems within the area on non-broadcast media (the more general CLNP model.)
IEEE 802.xに、(ISO 8802.x)はメディアをタイプして、アドレス(0セレクタを含んでいない)の最後の23ビットはマルチキャストがあるデータグラムを進めるとデータグラムがそのネットワークにマルチキャストか電波媒体アドレシングのどちらかで受け取られなかったならばルータから付属ネットワークまでのオプションが可能にされるときメディアアドレスを形成するためにインターネットに割り当てられたマルチキャストグループアドレスと組み合わせて使用されます。 ホストはルータへの全体のレベルの中でマルチキャストアドレスにそれを繰り返すと予想されて、私が非電波媒体の領域の中で領域か適切への反復コピーにシステムを終わらせるということであるメディアマルチキャストアドレス(IP catenetはモデル化する)かメディアユニキャストにマルチキャストデータグラムを送るかもしれません。(より一般的なCLNPはモデル化します。)
Network Layer Translation
ネットワーク層翻訳
The objective of translation 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 existing hosts must be able to interoperate essentially forever. (Non-CATNIP routers will probably be effectively eliminated at some point, except where they exist in their own remote or isolated corners.)
翻訳の目的はシステムをアップグレードさせることであることができます、ホストといかなるオーダーにおけるルータの両方も彼らの所有者で望んでいました。 組織は再構成も変更なしでいかなる他のもどんな与えられたシステムもアップグレードさせることができなければなりません、そして、既存のホストはいつまでも、本質的には共同利用できなければなりません。(非CATNIPルータはたぶん何らかのポイントで事実上排除されるでしょう、それらがそれら自身のリモートであるか孤立している角に存在するところを除いて。)
Each CATNIP system, whether host or router, must be able to recognize adjacent systems in the topology that are (only) IP version 4, CLNP, or IPX and call the appropriate translation routine just before sending the datagram.
それぞれのCATNIPシステムは、トポロジーの(単に)IPのバージョン4、CLNP、またはIPXである隣接しているシステムを認識して、データグラムを送るすぐ前に、ホストかルータであることにかかわらず適切な翻訳ルーチンを呼ぶことができなければなりません。
OSI CNLP
オウシCNLP
The translation between CLNP and the CATNIP compressed form of the datagrams is the simplest case for CATNIP, since the addresses are the same and need not be extended. The resulting CATNIP datagrams may omit the source and destination addresses as explained previously, and may be mixed with uncompressed datagrams on the same subnetwork link. Alternatively, a subnetwork may operate entirely in the CATNIP,
CLNPとデータグラムのCATNIP圧縮形の間の翻訳はCATNIPのための最も簡単なケースです、アドレスが同じであり、広げられる必要はないので。 結果として起こるCATNIPデータグラムは、以前に説明されるようにソースと送付先アドレスを省略して、同じサブネットワークリンクで解凍されたデータグラムに混ぜられるかもしれません。 あるいはまた、サブネットワークは完全にCATNIPで作動するかもしれません。
McGovern & Ullmann [Page 10] RFC 1707 CATNIP October 1994
マクガヴァンとウルマン[10ページ]RFC1707キャットニップ1994年10月
converting all transit traffic to CATNIP datagrams, even if FCIs that would make the compression effective are not available.
圧縮を有効にするFCIsが利用可能でなくても、CATNIPデータグラムへのすべてのトランジット交通を変換します。
Similarly, all network datagram formats with CATNIP mappings may be compressed into the common form, providing a uniform transit network service, with common routing protocols (such as IS-IS).
同様に、CATNIPマッピングがあるすべてのネットワークデータグラム形式が一般的なフォームに圧縮されるかもしれません、一定のトランジットネットワーク・サービスを提供して、一般的なルーティング・プロトコルで(-、)
Internet Protocol
インターネットプロトコル
All existing version 4 numbers are defined as belonging to the Internet by using a new AFI, to be assigned to IANA by the ISO. This document uses 192 at present for clarity in examples; it is to be replaced with the assigned AFI. The AFI specifies that the IDI is two bytes long, containing an administrative domain number.
すべての既存のバージョン4番号がISOによってIANAに割り当てられるのに新しいAFIを使用することによってインターネットに属すと定義されます。 このドキュメントは現在のところ、例における明快に192を使用します。 それは割り当てられたAFIに取り替えられることになっています。 管理ドメイン番号を含んでいて、AFIは、IDIが2バイト長であると指定します。
The AD (Administrative Domain), identifies an administration which may be an international authority (such as the existing InterNIC), 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.
AD(管理Domain)、国際機関であるかもしれない管理(既存のInterNICなどの)、国家の管理、または大きいマルチ組織(例えば、政府)を特定します。 考えはこれらのかなり多くの100が最初に、そして、結局数千か高々何万にあるべきでないということです。
AD numbers are assigned by IANA. Initially, the only assignment is the number 0.0, assigned to the InterNIC, encompassing the entire existing version 4 Internet.
AD番号はIANAによって割り当てられます。 初めは、唯一の課題が全体の既存のバージョン4インターネットを取り囲むInterNICに割り当てられたNo.0.0です。
The mapping from/to version 4 IP addresses:
/からバージョン4IPアドレスまでのマッピング:
+----------+----------+---------------+---------------------+
| length | AFI | IDI ... | DSP ... |
+----------+----------+---------------+---------------------+
| 7 | 192 | AD number | version 4 address |
+----------+----------+---------------+---------------------+
+----------+----------+---------------+---------------------+ | 長さ| AFI| イディ… | DSP… | +----------+----------+---------------+---------------------+ | 7 | 192 | AD番号| バージョン4 アドレス| +----------+----------+---------------+---------------------+
While the address (DSP) is initially always the 4 byte, version 4 address, it can be extended to arbitrary levels of subnetting within the existing Internet numbering plan. Hosts with DSPs longer than 4 bytes will not be able to interoperate with version 4 hosts.
初めは、アドレスである間、(DSP)はそうです。いつも4バイト、バージョン4アドレス、既存のインターネット付番プランの中で任意のレベルのサブネッティングにそれは広げることができます。 4バイトより長いDSPsのホストはバージョン4ホストと共に共同利用できないでしょう。
Novell IPX
ノベルIPX
The Internetwork Packet Exchange protocol, developed by Novell based on the XNS protocol (Xerox Network System) has many of the same capabilities as the Internet and OSI protocols. At first look, it appears to confuse the network and transport layers, as IPX includes both the network layer service and the user datagram service of the transport layer, while SPX (sequenced packet exchange) includes the IPX network layer and provides service similar to TCP or TP4. This
Internetwork Packet Exchangeプロトコル、(ゼロックスNetwork System)には、XNSプロトコルに基づくノベルによって開発されて、インターネットとOSIプロトコルと同じ能力の多くがあります。 最初の外観では、ネットワークとトランスポート層を混乱させるように見えます、IPXがネットワーク層サービスとトランスポート層のユーザデータグラムサービスの両方を含んでいるとき、SPX(パケット交換を配列する)はIPXネットワーク層を含んで、TCPかTP4と同様のサービスを提供しますが。 これ
McGovern & Ullmann [Page 11] RFC 1707 CATNIP October 1994
マクガヴァンとウルマン[11ページ]RFC1707キャットニップ1994年10月
turns out to be mostly a matter of the naming and ordering of fields in the packets, rather than any architectural difference.
ほとんど命名の問題であり、どんな建築違いよりもむしろパケットの分野を注文していることへの回転。
IPX uses a 32-bit LAN network number, implicitly concatenated with the 48-bit MAC layer address to form an Internet address. Initially, the network numbers were not assigned by any central authority, and thus were not useful for inter-organizational traffic without substantial prior arrangement. There is now an authority established by Novell to assign unique 32-bit numbers and blocks of numbers to organizations that desire inter-organization networking with the IPX protocol.
IPXは48ビットのMAC層のアドレスでそれとなく連結された、インターネット・アドレスを形成した32ビットのLANネットワーク・ナンバーを使用します。 初めは、ネットワーク・ナンバーは、どんな主要な権威によっても割り当てられないで、またその結果、かなりの先のアレンジメントなしで相互組織的な交通の役に立ちませんでした。 現在、IPXプロトコルによる相互組織ネットワークを望んでいる組織にユニークな32ビットの数とブロックの数を配属するためにノベルによって確立された権威があります。
The Novell/IPX numbering plan uses an ICD, to be assigned, to designate an address as an IPX address. This means Novell uses the authority (AFI=47)(ICD=Novell) and delegates assignments of the following 32 bits.
ノベル/IPX付番プランは、IPXアドレスとしてアドレスを指定するために割り当てられるのにICDを使用します。 これは、ノベルが以下の32ビットの権威(AFI=47)(ICDはノベルと等しい)と代表課題を使用することを意味します。
An IPX address in the common form looks like:
一般的なフォームでのIPXアドレスに似ています:
+----------+----------+---------------+---------------------+
| length | AFI | IDI ... | DSP ... |
+----------+----------+---------------+---------------------+
| 13 | 47 (hex) | Novell ICD | network+MAC address |
+----------+----------+---------------+---------------------+
+----------+----------+---------------+---------------------+ | 長さ| AFI| イディ… | DSP… | +----------+----------+---------------+---------------------+ | 13 | 47 (十六進法)| ノベルICD| ネットワーク+MACアドレス| +----------+----------+---------------+---------------------+
This will always be followed by two bytes of zero padding when it appears in a common network layer datagram. Note that the socket numbers included in the native form IPX address are part of the transport layer.
一般的なネットワーク層データグラムに現れるときそっと歩くゼロの2バイトはいつもこれのあとに続くでしょう。 固有のフォームIPXアドレスに含まれていたソケット番号がトランスポート層の一部であることに注意してください。
SIPP
SIPP
It may seem a little odd to describe the interaction with SIPP-16 (version 6 of IP) which is another proposed candidate for the next generation of network layer protocols. However, if SIPP-16 is deployed, whether or not as the protocol of choice for replacement of IP version 4, there will then be four network protocols to accommodate. It is prudent to investigate how SIPP-16 could then be integrated into the common addressing plan and datagram format.
ネットワーク層プロトコルの次世代の別の推薦された候補者であるSIPP-16(IPのバージョン6)との相互作用について説明するのは少し変に思えるかもしれません。 しかしながら、SIPP-16は配備されます、その時、IPバージョン4の交換のための選択のプロトコルとして対応する4つのネットワーク・プロトコルがあるか否かに関係なく。 次に、どう一般的なアドレシングプランとデータグラム形式とSIPP-16を統合できたかを調査するのは慎重です。
SIPP-16 defines 128 bit addresses, which are included in the NSAP addressing plan under the Internet AFI as AD number 0.1. It is not clear at this time what administration will hold the authority for the SIPP-16 numbering plan. This produces a 20 byte NSAPA, with the system ID field positioned exactly as expected by (e.g.) IS-IS.
SIPP-16は128のビット・アドレスを定義します。(ビット・アドレスはAD No.0.1としてインターネットAFIの下におけるNSAPアドレシングプランに含まれています)。 どんな管理がSIPP-16付番プランのための権威を保持するかは、このとき、明確ではありません。 これはちょうど予想されるように置かれたシステムID野原がある20バイトのNSAPAを生産します。 IS-IS。
McGovern & Ullmann [Page 12] RFC 1707 CATNIP October 1994
マクガヴァンとウルマン[12ページ]RFC1707キャットニップ1994年10月
+----------+----------+---------------+---------------------+
| length | AFI | IDI ... | DSP ... |
+----------+----------+---------------+---------------------+
| 19 | 192 | AD (0.1) | SIPP-16 address |
+----------+----------+---------------+---------------------+
+----------+----------+---------------+---------------------+ | 長さ| AFI| イディ… | DSP… | +----------+----------+---------------+---------------------+ | 19 | 192 | 西暦(0.1)| SIPP-16アドレス| +----------+----------+---------------+---------------------+
The SIPP-16 addressing method (the definition of the 128 bits) will not be described here.
SIPP-16アドレス指定法(128ビットの定義)はここで説明されないでしょう。
The SIPP proposal also includes an encapsulated-tunnel proposal called IPAE, to address some of the issues that are designed into CATNIP. The CATNIP direct translation does not use the SIPP-IPAE packet formats. IPAE also specifies a "mapping table" for prefixes. This table is kept up-to-date by periodic FTP transfers from a "central site." The CATNIP definitions leave the problem of prefix selection when converting into SIPP firmly within the scope of the SIPP-IPAE proposal, and possible methods are not described here.
また、SIPP提案はCATNIPに設計されている問題のいくつかを記述するためにIPAEと呼ばれる要約のトンネル提案を含んでいます。 CATNIPのダイレクト翻訳はSIPP-IPAEパケット・フォーマットを使用しません。 また、IPAEは「マッピングテーブル」を接頭語に指定します。 このテーブルは「主要なサイト」からの周期的なFTP転送で最新に保たれます。 SIPP-IPAE提案の範囲の中でしっかりSIPPに変換するとき、CATNIP定義は接頭語選択の問題を残します、そして、可能な方法はここで説明されません。
In translating from SIPP (IPv6) to CATNIP (IPv7), the only unusual aspect is that SIPP defines some things that are normally considered options to be "payloads" overloaded onto the transport protocol numbering space. Fortunately, the only one that need be considered is fragmentation; a fragmented SIPP datagram may need to be reassembled prior to conversion. Other "payloads" such as routing are ignored (translated verbatim) and will normally simply fail to achieve the desired effect.
SIPP(IPv6)からCATNIP(IPv7)まで翻訳するのにおいて、唯一の珍しい局面はSIPPが通常、トランスポート・プロトコル付番スペースに積みすぎられた「ペイロード」になるようにオプションであると考えられるいくつかのことを定義するということです。 幸い、考えられなければならない唯一無二は断片化です。 断片化しているSIPPデータグラムは、変換の前に組み立て直される必要があるかもしれません。 ルーティングなどの他の「ペイロード」は、無視されて(逐語的に翻訳されます)、通常、絶対に期待される効果を発揮しないでしょう。
Translation to SIPP is simple, except for the difficult problem of inventing the "prefix" if an implementation wants to support translating Internet AD 0.0 numbers into the SIPP addressing domain.
SIPPへの翻訳は簡単です、実現がSIPPアドレス指定領域への西暦0.0年番号をサポート翻訳インターネットに必要とするなら「接頭語」を発明する難問を除いて。
Internet DNS
インターネットDNS
CATNIP addresses are represented in the DNS with the NSAP RR. The data in the resource record is the NSAP, including the zero selector at the end. The zone file syntax for the data is a string of hexadecimal digits, with a period "." inserted between any two octets where desired for readability. For example:
CATNIPアドレスはNSAP RRと共にDNSに表されます。 リソースレコードのデータはゼロを含んでいるNSAPです。終わりのセレクタ。 「データのためのゾーンファイル構文は一連の16進数字です、期間で」。. 」 読み易さに必要であるところでどんな2つの八重奏の間にも挿入されます。 例えば:
The inverse (PTR) zone is .NSAP.INT, with the CATNIP address (reversed). That is, like .IN-ADDR.ARPA, but with .NSAP.INT instead. The nibbles are represented as hexadecimal digits.
逆さの(PTR)ゾーンはCATNIPアドレスがある.NSAP.INT(逆にされる)です。 それは、.IN-ADDR.ARPAに似ていますが、代わりに.NSAP.INTと共にいます。 少量が16進数字として表されます。
This respects the difference in actual authority: the IANA is the authority for the entire space rooted in .IN-ADDR.ARPA. in the version 4 Internet, while in the new Internet it holds the authority only for 0.C.NSAP.INT. (Following the example of 192 as the AFI value.) The domain 0.0.0.0.0.C.NSAP.INT is to be delegated by IANA to
これは実際の権威の違いを尊敬します: IANAは.IN-ADDR.ARPAに根づいている全体のスペースへの権威です。新しいインターネットにある間、バージョン4インターネットでは、それは0.C. NSAP.INTのためだけの権威を保持します。 (AFI値として192に関する例に倣っています。) ドメイン0.0.0.0.0.C. NSAP.INTはIANAによって代表として派遣されることになっています。
McGovern & Ullmann [Page 13] RFC 1707 CATNIP October 1994
マクガヴァンとウルマン[13ページ]RFC1707キャットニップ1994年10月
the InterNIC. (Understanding that in present practice the InterNIC is the operator of the authoritative root.)
InterNIC。 (実際には現在のそれを理解していて、InterNICは正式の根のオペレータです。)
Security Considerations
セキュリティ問題
The CATNIP design permits the direct use of the present proposals for network layer security being developed in the IPSEC WG of the IETF. There are a number of detailed requirements; the most relevant being that network layer datagram translation must not affect (cannot affect) the transport layers, since the TPDU is mostly inaccessible to the router. For example, the translation into IPX will only work if the port numbers are shadowed into the plaintext security header.
CATNIPデザインは現在の提案のIETFのIPSEC WGで開発されるネットワーク層セキュリティのダイレクト使用を可能にします。 多くの詳細な要件があります。 最も関連しているのは、ネットワーク層データグラム翻訳がトランスポート層に影響してはいけないという(影響できません)ことです、TPDUがルータにほとんど近づきがたいので。 例えば、ポートナンバーが平文セキュリティヘッダーに影でおおわれる場合にだけ、IPXへの翻訳は働くでしょう。
References
参照
[Chapin93] Chapin, L., and D. Piscitello, "Open Systems
Networking", Addison-Wesley, Reading, Massachusetts,
1993.
[Chapin93] チェーピン、L.とD.Piscitello、「オープンシステムネットワーク」、アディソン-ウエスリー、読書、マサチューセッツ、1993
[Perlman92] Perlman, R., "Interconnections: Bridges and Routers"
Addison-Wesley, Reading, Massachusetts, 1992.
[Perlman92]パールマン、R.、「インタコネクト:」 「橋とルータ」アディソン-ウエスリー、読書、マサチューセッツ、1992。
[RFC791] Postel, J., Editor, "Internet Protocol - DARPA
Internet Program Protocol Specification", STD 5, RFC
791 USC/Information Sciences Institute, September
1981.
[RFC791]ポステル、J.、エディタ、「インターネットは議定書を作ります--DARPAインターネットプログラムプロトコル仕様」、STD5、RFC791USC/情報科学研究所、1981年9月。
[RFC792] Postel, J., Editor, "Internet Control Message
Protocol - DARPA Internet Program Protocol
Specification", STD 5, RFC 792, USC/Information
Sciences Institute, September 1981.
[RFC792]ポステル、J.、エディタ、「インターネットはメッセージプロトコルを制御します--DARPAインターネットプログラムプロトコル仕様」、STD5、RFC792、科学が設けるUSC/情報、1981年9月。
[RFC793] Postel, J., Editor, "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", RFC 801,
USC/Information Sciences Institute, November, 1981.
[RFC801] ポステル、J.、「NCP/TCP変遷プラン」、RFC801、科学が1981年11月に設けるUSC/情報。
[RFC1191] Mogul, J., and S. Deering, "Path MTU Discovery",
RFC 1191, DECWRL, Stanford University, November,
1990.
[RFC1191] ムガール人、J.とS.デアリング、「経路MTU発見」、RFC1191、DECWRL、スタンフォード大学、1990年11月。
[RFC1234] Provan, D., "Tunneling IPX Traffic Through IP
Networks", RFC 1234, Novell, Inc., June 1991.
[RFC1234] Provan、D.、「IPネットワークを通したトンネリングIPX交通」、RFC1234、ノベルInc.、1991年6月。
McGovern & Ullmann [Page 14] RFC 1707 CATNIP October 1994
マクガヴァンとウルマン[14ページ]RFC1707キャットニップ1994年10月
[RFC1247] Moy, J., "OSPF Version 2", RFC 1247, Proteon, Inc.,
July 1991.
[RFC1247]Moy、J.、「OSPF、バージョン2インチ、RFC1247、Proteon Inc.、1991インチ年7月。
[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月。
[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, BAARNet, cicso, Merit, OARnet,
June 1992.
[RFC1338] フラー、V.、李、T.、ユー、J.、およびK.Varadhan、「スーパーネッティング:」 Merit、OARnet、「Address AssignmentとAggregation Strategy」(RFC1338、BAARNet)がcicsoする、6月1992日
[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月。
[RFC1466] Gerich, E., "Guidelines for Management of IP Address
Space", RFC 1466, Merit, May 1993.
[RFC1466] Gerich、「IP管理アドレス空間のためのガイドライン」(RFC1466)が1993年5月に値するE.。
[RFC1475] Ullmann, R., "TP/IX: The Next Internet", RFC 1475,
Process Software Corporation, June 1993.
[RFC1475]ウルマン、R.、「TP/IX:」 「次のインターネット」、RFC1475は1993年6月にソフトウェア社を処理します。
[RFC1476] Ullmann, R., "RAP: Internet Route Access Protocol",
RFC 1476, Process Software Corporation, June 1993.
[RFC1476] ウルマン、R.は「以下を叩きます」。 「インターネットルートアクセス・プロトコル」、RFC1476は1993年6月にソフトウェア社を処理します。
[RFC1561] Piscitello, D., "Use of ISO CLNP in TUBA
Environments", RFC 1561, Core Competence, December
1993.
[RFC1561] Piscitello、D.、「チューバ環境におけるISO CLNPの使用」、RFC1561、コアコンピタンス、1993年12月。
McGovern & Ullmann [Page 15] RFC 1707 CATNIP October 1994
マクガヴァンとウルマン[15ページ]RFC1707キャットニップ1994年10月
Authors' Addresses
作者のアドレス
Michael McGovern Sunspot Graphics
マイケルマクガヴァン太陽黒点グラフィックス
EMail: scrivner@world.std.com
メール: scrivner@world.std.com
Robert Ullmann Lotus Development Corporation 1 Rogers Street Cambridge, MA 02142
ロバートウルマンLotus Development Corporation1ロジャース・通りケンブリッジ、MA 02142
Phone: +1 617 693 1315 EMail: rullmann@crd.lotus.com
以下に電話をしてください。 +1 1315年の617 693メール: rullmann@crd.lotus.com
McGovern & Ullmann [Page 16]
マクガヴァンとウルマン[16ページ]
一覧
スポンサーリンク
