RFC1682 日本語訳
1682 IPng BSD Host Implementation Analysis. J. Bound. August 1994. (Format: TXT=22295 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group J. Bound Request for Comments: 1682 Digital Equipment Corporation Category: Informational August 1994
ネットワークワーキンググループJ.はコメントを求める要求を縛りました: 1682年のDECカテゴリ: 情報の1994年8月
IPng BSD Host Implementation Analysis
IPng BSDホスト導入分析
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 このメモはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Abstract
要約
This document was submitted to the IETF IPng area in response to RFC 1550. Publication of this document does not imply acceptance by the IPng area of any ideas expressed within. Comments should be submitted to the big-internet@munnari.oz.au mailing list.
RFC1550に対応してIETF IPng領域にこのドキュメントを提出しました。 このドキュメントの公表はどんな考えのIPng領域のそばでも中で言い表された状態で承認を含意しません。 big-internet@munnari.oz.au メーリングリストにコメントを提出するべきです。
Overview
概要
This IPng white paper, IPng BSD Host Implementation Analysis, was submitted to the IPng Directorate to provide a BSD host point of reference to assist with the engineering considerations during the IETF process to select an IPng proposal. The University of California Berkeley Software Distribution (BSD) TCP/IP (4.3 + 4.4) system implementation on a host is used as a point of reference for the paper.
IETFプロセスの間の工学問題でIPng提案を選択するのを促進する参照のBSDホストポイントを提供するために、このIPng白書(IPng BSD Host Implementation Analysis)をIPng Directorateに提出しました。 ホストにおけるカリフォルニア大学バークレイ校Software Distribution(BSD)TCP/IP(4.3+4.4)システムの実現は紙の参照のポイントとして使用されます。
This document only reflects the author's personal analysis based on research and implementation experience for IPng, and does not represent any product or future product from any host vendor. Nor should it be construed that it is promoting any specific IPng at this time.
このドキュメントだけが、IPngのために研究と実装経験に基づく作者の個人的な分析を反映して、どんなホストベンダーからもどんな製品や将来の製品も代表しません。 また、このときどんな特定のIPngも促進しているのは、解釈されるべきではありません。
Acknowledgments
承認
The author would like to acknowledge the many host implementation discussions and inherent knowledge gained from discussions with the following persons within Digital over the past year: Peter Grehan, Eric Rosen, Dave Oran, Jeff Mogul, Bill Duane, Tony Lauck, Bill Hawe, Jesse Walker, John Dustin, Alex Conta, and Fred Glover. The author would also like to acknowledge like discussions from outside his company with Bob Hinden (SUN), Bob Gilligan (SUN), Dave Crocker (SGI), Dave Piscitello (Core Competence), Tracy Mallory (3Comm), Rob Ullmann (Lotus), Greg Minshall (Novell), J Allard (Microsoft), Ramesh Govinden (Bellcore), Sue Thompson (Bellcore), John Curran (NEARnet),
作者は、多くのホスト導入議論と固有の知識が昨年Digitalの中で以下の人々との議論から得たと認めたがっています: ピーターGrehan、エリック・ローゼン、デーヴ・オラン、ジェフ・ムガール人、ビル・ドウェイン、トニーLauck、ビルHawe、ジェシー・ウォーカー、ジョン・ダスティン、アレックス・コンタ、およびフレッドGloverまた、作者はボブHinden(SUN)、ボブ・ギリガン(SUN)、デーヴ・クロッカー(SGI)、デーヴPiscitello(コアCompetence)、トレーシーMallory(3Comm)、ロブ・ウルマン(ロータス)、グレッグMinshall(ノベル)、Jアラード(マイクロソフト)、Ramesh Govinden(Bellcore)、スートンプソン(Bellcore)、ジョン・カラン(NEARnet)と共に議論のように外部から彼の会社を承認したがっています。
Bound [Page 1] RFC 1682 IPng BSD Host Implementation Analysis August 1994
制限された[1ページ]RFC1682IPng BSDは1994年8月に実装分析を主催します。
Christian Huitema (INRIA), and Werner Volgels (INESC). The author would also like to thank Digital Equipment Corporation for the opportunity to work on IPng within the IETF as part of his job.
クリスチャンのHuitema(INRIA)、およびヴェルナーVolgels(INESC)。 また、作者は彼の仕事の一部としてIETFの中でIPngに働く機会についてDECに感謝したがっています。
1. Introduction
1. 序論
A host in the context of this white paper is a system that contains an operating system supporting a network subsystem as one of its parts, and an interprocess communications facility to access that network subsystem. These hosts are often referenced as a Workstation, Server, PC, Super Computer, Mainframe, or an Embedded System (Realtime Devices).
この白書の文脈のホストはそのネットワークサブシステムにアクセスするために部品、およびプロセス間通信施設の1つとしてネットワークサブシステムをサポートするオペレーティングシステムを含むシステムです。 これらのホストはWorkstation、Server、PC、Superコンピュータ、Mainframe、またはEmbedded System(リアルタイムでDevices)としてしばしば参照をつけられます。
IPng will require changes to a hosts network software architecture. Those changes should be as transparent as possible to the existing IPv4 applications executing on hosts.
IPngはホストネットワークソフトウェア・アーキテクチャへの変化を必要とするでしょう。 それらの変化はできるだけホストの上で実行される既存のIPv4アプリケーションに透明であるべきです。
After discussing the network software architecture for a BSD host the paper will discuss the perceived network software alterations, extended capabilities, transition software, and a deployment consideration for IPng hosts.
BSDホストのためにネットワークソフトウェア・アーキテクチャについて議論した後に、論文はIPngホストのための知覚されたネットワークソフトウェア変更、拡張能力、変遷ソフトウェア、および展開の考慮について議論するでしょう。
The inclusive OR of all IPng proposals was used to develop the engineering considerations discussed in this paper.
すべてのIPng提案の包括的なORは、この紙で議論した工学問題を開発するのに使用されました。
2. Network Software Architecture
2. ネットワークソフトウェア・アーキテクチャ
The BSD host network software architecture consists essentially of three components: the interprocess communications facility, the network communications subsystem, and the network protocols supported. These three components are tightly coupled and must be integrated in a way that affords high performance for the applications that are dependent on these components to interoperate efficiently. A BSD host implementation view of the TCP/IP protocol suite is depicted in the following network architecture diagram.
BSDホストネットワークソフトウェア・アーキテクチャは本質的には3つのコンポーネントから成ります: プロセス間通信施設、ネットワークコミュニケーションサブシステム、およびプロトコルがサポートしたネットワーク。 これらの3つのコンポーネントが、密結合であり、効率的に共同利用するためにこれらのコンポーネントに依存するアプリケーションのための高性能を提供する方法で統合していなければなりません。 TCP/IPプロトコル群のBSDホスト導入視点は以下のネットワークアーキテクチャダイヤグラムで表現されます。
Bound [Page 2] RFC 1682 IPng BSD Host Implementation Analysis August 1994
制限された[2ページ]RFC1682IPng BSDは1994年8月に実装分析を主催します。
+-----------------------------------------------------------------+ | Application Layer | | | | Socket and Network Library APIs | | | | BIND DNS | | SNMP Management | | User Space | +-----------------------------------------------------------------+ | Kernel Space AF_INET | | Communications Domain | | Socket Layer | | | | Transport Layer TCP & UDP | | Queues/Control | | Blocks | | Network Layer | | +-----------------------------------+ | | | IPv4 Modules Discovery Multicast | | | | ICMP IGMP | | | | Routing | Routing | | | RIP EGP | Tables | | | OSPF BGP | | | | I-IS-IS IDRP | | | +-----------------------------------+ | | Link Dependent Layer | | +-----------------------------------+ | | | ARP, RARP, InARP, NCPs, Addr Tbls | | | +-----------------------------------+ | | Discovery & Interface | | Cache | | Data Link Layer | | +-----------------------------------+ | | | Ethernet, FDDI, ATM, HIPPI, PPP | | | +-----------------------------------+ | +-----------------------------------------------------------------+
+-----------------------------------------------------------------+ | 応用層| | | | ソケットとネットワーク図書館API| | | | ひものDNS| | SNMP管理| | ユーザスペース| +-----------------------------------------------------------------+ | カーネルスペースAF_INET| | コミュニケーションドメイン| | ソケットレイヤー| | | | トランスポート層TCP&UDP| | 待ち行列/コントロール| | ブロック| | ネットワーク層| | +-----------------------------------+ | | | IPv4モジュール発見マルチキャスト| | | | ICMP IGMP| | | | ルート設定| ルート設定| | | EGPを裂いてください。| テーブル| | | OSPF BGP| | | | I-IS-IS IDRP| | | +-----------------------------------+ | | 依存する層をリンクしてください。| | +-----------------------------------+ | | | アルプ、RARP、InARP、NCP、Addr Tbls| | | +-----------------------------------+ | | 発見とインタフェース| | キャッシュ| | データ・リンク層| | +-----------------------------------+ | | | イーサネット、FDDI、気圧、HIPPI、ppp| | | +-----------------------------------+ | +-----------------------------------------------------------------+
2.1 Interprocess Communications Facility
2.1 プロセス間通信施設
The interprocess communications (IPC) facilities includes three critical parts:
プロセス間通信(IPC)施設は3つの重要な部品を含んでいます:
1. The IPC mechanism to the network communications subsystem.
2. The ability to access a network protocol set within that
subsystem.
3. The structures supporting the network communications
subsystem.
1. ネットワークコミュニケーションサブシステムへのIPCメカニズム。 2. ネットワーク・プロトコルにアクセスする能力はそのサブシステムの中にセットしました。 3. ネットワークコミュニケーションサブシステムをサポートする構造。
Bound [Page 3] RFC 1682 IPng BSD Host Implementation Analysis August 1994
制限された[3ページ]RFC1682IPng BSDは1994年8月に実装分析を主催します。
The IPC facility has two implementation parts. The part in user space and the part in kernel space within the operating system. This is often not differentiated and why in the previous network architecture diagram you will see sockets in both user and kernel space. An IPC supports in user space an application program interface (API) which application developers use to access the network communications features of the host. These APIs have corresponding functions in the kernel space which execute the functions requested by the user space requests through the APIs.
IPC施設には、2つの実装の部品があります。 ユーザスペースの部分とオペレーティングシステムの中のカーネルスペースの部分。 これはしばしば差別化されるというわけではありません、そして、あなたがそうする前のネットワークアーキテクチャダイヤグラムによるなぜがユーザとカーネルスペースの両方でソケットを見るか。 IPCはユーザスペースでアプリケーション開発者がホストのネットワークコミュニケーション機能にアクセスするのに使用する適用業務プログラム・インタフェース(API)をサポートします。 これらのAPIには、カーネルスペースでのAPIを通したユーザ宇宙要求で要求された機能を実行する対応する機能があります。
The sockets paradigm on a BSD host defines the data structure of the network address within a selected protocol family (communications domain) in the network subsystem. This data structure consists of an address family, a port for the protocol selected, and a network address.
BSDホストの上のソケットパラダイムは選択されたプロトコルファミリー(コミュニケーションドメイン)の中でネットワークサブシステムでネットワーク・アドレスのデータ構造を定義します。 このデータ構造はアドレスファミリー、選択されたプロトコルのためのポート、およびネットワーク・アドレスから成ります。
The IPC facility on a host is dependent upon its interface to the BIND DNS application which is the defacto method when using TCP/IP to retrieve network addresses.
ホストの上のIPC施設はネットワーク・アドレスを検索するのにTCP/IPを使用するとき、事実上のメソッドであるBIND DNSアプリケーションへのインタフェースに依存しています。
Other interfaces that may be required by applications to properly set up the network connection within the IPC facility include: setting/getting options for the protocols used, obtaining/accessing information about networks, protocols, and network services, and sending/transmitting datagrams.
IPC施設の中で適切にネットワーク接続をセットアップするのにアプリケーションで必要であるかもしれない他のインタフェースは: ネットワーク、プロトコル、ネットワーク・サービス、および発信/伝えるデータグラムの情報に得るか、またはアクセスして、使用されるプロトコルのためのオプションを設定するか、または得ます。
2.2 Network Communications Subsystem
2.2ネットワークコミュニケーションサブシステム
The network communications subsystem consists of the following generic parts as depicted in the previous network architecture diagram: transport layer, network layer, link dependent layer, and data link layer. These may not be implemented as true distinct layers on a BSD host, but they are referenced in this white paper in that manner for purposes of discussion.
ネットワークコミュニケーションサブシステムは前のネットワークアーキテクチャダイヤグラムで表現されるように以下の汎用パーツから成ります: トランスポート層、ネットワーク層は依存する層、およびデータ・リンク層をリンクします。 これらは本当の異なった層としてBSDホストの上で実装されないかもしれませんが、それらはそんなふうに議論の目的のためにこの白書で参照をつけられます。
The transport layer supports the application interface into the network communications subsystem and sets up the parametric pieces to initiate and accept connections. The transport layer performs these functions through requests to the lower layers of the network communications subsystem. The transport layer also supports the queues and protocol control blocks for specific network connections.
トランスポート層は、ネットワークコミュニケーションサブシステムにアプリケーション・インターフェースをサポートして、接続を開始して、受け入れるためにパラメトリック断片をセットアップします。 トランスポート層はネットワークコミュニケーションサブシステムの下層への要求でこれらの機能を実行します。 また、トランスポート層は、特定のネットワーク接続のために待ち行列とプロトコルが制御ブロックであるとサポートします。
The network layer supports the modules to build and extend the network layer datagram, the control protocol datagrams, and the routing abstraction on the host. This layer of the network communications subsystem on a BSD host is often extended to provide both interior and exterior routing functionality.
ネットワーク層は、ホストでネットワーク層データグラム、制御プロトコルデータグラム、およびルーティング抽象化を組立てて、広げるためにモジュールをサポートします。 BSDホストの上のネットワークコミュニケーションサブシステムのこの層は、内部の、そして、外の両方のルーティングの機能性を提供するためにしばしば広げられます。
Bound [Page 4] RFC 1682 IPng BSD Host Implementation Analysis August 1994
制限された[4ページ]RFC1682IPng BSDは1994年8月に実装分析を主催します。
The link dependent layer supports the modules that provide an interface for the network communications subsystem to map network addresses to physical addresses, and build the necessary cache so this information is available to the host network software.
この情報がホストネットワークソフトウェアに利用可能であることで、依存する層がネットワーク・アドレスを物理アドレスに写像して、必要なキャッシュを築き上げるためにネットワークコミュニケーションサブシステムにインタフェースを提供するモジュールをサポートするリンク。
On a BSD host the network layer and link dependent layer together provide system discovery for hosts and routers.
ネットワーク層とリンク扶養家族が一緒に層にするBSDホストの上では、ホストとルータのためのシステム発見を提供してください。
The data link layer supports the modules that define the structures for communicating with the hardware media used by the host on the local network.
データ・リンク層は企業内情報通信網でホストによって使用されたハードウェアメディアとコミュニケートするために構造を定義するモジュールをサポートします。
2.3 Network Protocols
2.3 ネットワークプロトコル
The TCP/IP protocol suite as defined by the IETF RFC specifications are the set of network protocols used by this white paper for reference.
IETF RFC仕様で定義されるTCP/IPプロトコル群は参照にこの白書によって使用されるネットワーク・プロトコルのセットです。
3. Network Software Alterations
3. ネットワークソフトウェア変更
The IPng network software alterations to a BSD host perceived at this time are as follows:
このとき知覚されているBSDホストへのIPngネットワークソフトウェア変更は以下の通りです:
1. Applications Embedding IPv4 Addresses.
2. Transport Interfaces and Network APIs.
3. Socket Layer and Structures.
4. Transport Layer.
5. Network Layer Components.
6. Link dependent Layer.
1. IPv4アドレスを埋め込むアプリケーション。 2. インタフェースとネットワークAPIを輸送してください。 3. ソケットレイヤーと構造。 4. 層を輸送してください。 5. ネットワーク層コンポーネント。 6. 依存するLayerをリンクしてください。
3.1 Applications Embedding IPv4 Addresses
3.1 IPv4アドレスを埋め込むアプリケーション
Internet style applications in this white paper are the set of protocols defined for an end user using TCP/IP to exchange messages, transfer files, and establish remote login sessions.
この白書におけるインターネットスタイルアプリケーションはエンドユーザのためにメッセージを交換して、ファイルを移して、リモート・ログインセッションを証明するのにTCP/IPを使用することで定義されたプロトコルのセットです。
Applications use the sockets network APIs to maintain an opaque view of the network addresses used to support connections across a network. Opaque in this context means that the application determines the network address for the connection and then binds that address to a socket. The application then uses the reference defined for that socket to receive and transmit data across a network.
ソケットがネットワーク・アドレスの不明瞭な視点であることを支持するためにAPIをネットワークでつなぐアプリケーション使用は以前はネットワークの向こう側によく接続をサポートしていました。 不透明なものは、アプリケーションが接続のためにネットワーク・アドレスを決定して、次に、そのアドレスをソケットに縛ることをこのような関係においては意味します。 そして、アプリケーションはそのソケットがネットワークの向こう側にデータを受け取って、送るように定義された参照を使用します。
An application that embeds an IPv4 network address within its datagram has made an underlying assumption that the format of that address is permanent. This will cause a great problem when IPng causes addresses to change. Thus far only one Internet style application has been determined to cause this problem and that is FTP
データグラムの中にIPv4ネットワーク・アドレスを埋め込むアプリケーションはそのアドレスの形式が永久的であるという基本的な仮定をしました。 IPngがアドレスを変えさせると、これは重大な問題を引き起こすでしょう。 これまでのところ、1つのインターネットスタイルアプリケーションだけがこの問題を引き起こすことを決定しています、そして、それはFTPです。
Bound [Page 5] RFC 1682 IPng BSD Host Implementation Analysis August 1994
制限された[5ページ]RFC1682IPng BSDは1994年8月に実装分析を主催します。
[1,2].
[1,2].
3.2 Transport Interfaces and Network APIs
3.2 輸送インタフェースとネットワークAPI
The transport interface and network API enhancements that must take place on a BSD host because of IPng are alterations that affect the size of the network address used by the socket data structure. Depending on how this is implemented on the host, supporting both IPv4 and IPng could require existing IPv4 applications to be recompiled. In the worst case it could require modifications to the existing IPv4 applications software that accesses the network communications subsystem.
IPngのためにBSDホストの上で行われなければならない輸送インタフェースとネットワークAPI増進はソケットデータ構造によって使用されるネットワーク・アドレスのサイズに影響する変更です。 IPv4とIPngの両方をサポートして、これがホストの上でどう実装されるかによるのは、既存のIPv4アプリケーションが再コンパイルされるのを必要とするかもしれません。 最悪の場合にはそれはネットワークコミュニケーションサブシステムにアクセスする既存のIPv4アプリケーションソフトウェアへの変更を必要とするかもしれません。
There will have to be enhancements to the network APIs that an application uses to retrieve BIND DNS records to differentiate between IPv4 and IPng address requests.
そこでは、ネットワークAPIへのアプリケーションがIPv4を区別するためにBIND DNS記録を検索するのに使用する増進とIPngアドレス要求でなければならないでしょう。
The network API enhancements and how they are implemented will affect the capability of any IPng proposal on a BSD host to be able to interoperate between an IPv4 only, an IPng only, and an IPng-IPv4 host system.
ネットワークAPI増進とそれらがどう実装されるかがIPv4だけと、IPngだけと、IPng-IPv4ホストシステムの間に共同利用できるというBSDホストにおけるどんなIPng提案の能力にも影響するでしょう。
Depending on the IPng proposal selected the network options, services, and management objects will have to be extended at the transport interface so those features can be accessed by applications software.
IPng提案によるのは、アプリケーションソフトウェアからそれらの特徴にアクセスできるようにオブジェクトが持っているネットワークオプション、サービス、および管理が輸送インタフェースで広げられるのを選択しました。
3.3 Socket Layer and Structures
3.3 ソケットレイヤーと構造
The socket layer and structures will require changes to support any IPng proposals network address. In addition new or removed options and services will need to be incorporated into the socket abstraction within the network communications subsystem.
ソケットレイヤーと構造は、どんなIPngも提案ネットワーク・アドレスであるとサポートするために釣り銭がいるでしょう。 さらに、新しいか取り除かれたオプションとサービスは、ネットワークコミュニケーションサブシステムの中でソケット抽象化に組み入れられる必要があるでしょう。
3.4 Transport Layer
3.4 トランスポート層
The transport layer will need to be modified to support any new or removed services proposed by an IPng solution set. The transport layer will become more overloaded to support the binding of either the IPv4 or IPng network layer components to differentiate the services and structures available to a host application. The overload will also take place to support functionality removed in the network layer and moved to the transport layer if proposed by an IPng solution.
トランスポート層は、IPng解集合によって提案されたどんな新しいか取り除かれたサービスもサポートするように変更される必要があるでしょう。 トランスポート層はホストアプリケーションに利用可能なサービスと構造を差別化するためにIPv4かIPngネットワーク層の部品をどちらかの結合に支えるためにさらに積みすぎられるようになるでしょう。 また、オーバーロードはIPngソリューションによって提案されるなら、ネットワーク層で取り除かれて、トランスポート層に動かされたサポートの機能性に行われるでしょう。
It will also take some design thought to implement IPng so the hundreds of man years invested in performance improvements in the host transport layer are maintained. This must be analyzed in depth
また、それがIPngを実装すると考えられた何らかのデザインを取るので、ホストトランスポート層における性能改善に投資された何百人年も維持されます。 これを徹底的に分析しなければなりません。
Bound [Page 6] RFC 1682 IPng BSD Host Implementation Analysis August 1994
制限された[6ページ]RFC1682IPng BSDは1994年8月に実装分析を主催します。
and should be part of the operational testing of any IPng proposal.
そして、どんなIPng提案の操作上のテストの一部であるべきです。
3.5 Network Layer Components
3.5 ネットワーク層コンポーネント
The network layer components for IPng will require the greatest alterations on a host. In addition a host will be required to maintain an integrated network layer below the transport layer software to support either the IPng or IPv4 network layer and associated components.
IPngのためのネットワーク層コンポーネントはホストで最も大きい変更を必要とするでしょう。 さらに、ホストが、IPngかIPv4ネットワーク層と関連コンポーネントをサポートするためにトランスポート層ソフトウェアの下で統合ネットワーク層を維持するのに必要でしょう。
Depending on the IPng selected the host alterations to the network layer components will range from complete replacement with new protocols to extensions to existing IPv4 network layer protocols to support IPng.
IPngによるのはコンポーネントがIPngをサポートするために既存のIPv4ネットワーク層プロトコルに新しいプロトコルとの完全な交換から拡大まで及ばせるネットワーク層にホスト変更を選択しました。
All IPng proposals will affect the BSD host routing abstraction to maintain host software that supports interior and exterior routing. Depending on the proposal selected those changes can cause either a complete new paradigm or an update to the existing IPv4 paradigm.
すべてのIPng提案が内部の、そして、外のルーティングをサポートするホストソフトウェアを維持するために抽象化を発送するBSDホストに影響するでしょう。 選択された提案によって、それらの変化は完全な新しい発想かアップデートのどちらかを既存のIPv4パラダイムに引き起こす場合があります。
System discovery of nodes on the local subnetwork or across an internetwork path in all IPng proposals will require changes to the BSD host software network layer component.
地方のサブネットワークの上、または、インターネットワーク経路中のすべてのIPng提案におけるノードのシステム発見はBSDホストソフトウェアネットワーク層の部品への変化を必要とするでしょう。
3.6 Link dependent Layer
3.6 リンクの依存するLayer
The link dependent layer on a host will need to accommodate new IPng addresses and the system discovery models of any IPng proposal.
ホストの上の依存する層がどんなIPng提案の新しいIPngアドレスとシステム発見モデルにも対応するために必要とするリンク。
4. Extended Capabilities with IPng
4. IPngがある拡張能力
Extended capabilities that could be implemented by BSD hosts are listed below. Many of these capabilities exist today with IPv4, but may require changes with the implementation of IPng. Some of them will be new capabilities.
BSDホストが実装することができた拡張能力は以下に記載されています。 これらの能力の多くが、今日IPv4と共に存在しますが、IPngの実装で釣り銭がいるかもしれません。 それらのいくつかが新しい能力になるでしょう。
4.1 Autoconfiguration and Autoregistration
4.1 自動構成とAutoregistration
Today hosts can provide autoconfiguration with DHCP using IPv4 addresses. IPng hosts will be faced with having to provide support for existing IPv4 addresses and the new IPng addresses. In addition the boot-strap protocol BOOTP used to boot minimal BSD host configurations (e.g., diskless nodes) will need to be supported by IPng hosts.
今日、ホストは、IPv4アドレスを使用することでDHCPを自動構成に提供できます。 IPngホストはIPv4アドレスと新しいIPngアドレスを存在するサポートに提供しなければならないのに面するでしょう。 さらに、BOOTPが最小量のBSDホスト構成(例えば、ディスクレスノード)をブートするのに使用したブートストラッププロトコルは、IPngホストによってサポートされる必要があるでしょう。
Bound [Page 7] RFC 1682 IPng BSD Host Implementation Analysis August 1994
制限された[7ページ]RFC1682IPng BSDは1994年8月に実装分析を主催します。
4.2 PATH MTU Discovery
4.2 経路MTU発見
PATH MTU discovery appears to be something each proposal is considering. Alterations to the existing implementation of PATH MTU are perceived because changes are expected in system discovery.
PATH MTU発見は各提案が考えている何かであるように見えます。 変化がシステム発見で予想されるので、PATH MTUの既存の実装への変更は知覚されます。
4.3 Multicast
4.3 マルチキャスト
Each proposal has depicted alterations to Multicast that will affect present BSD host implementations of IPv4 Multicast. In addition it appears that the IPv4 unicast broadcast will be replaced by a multicast broadcast.
各提案はIPv4 Multicastの現在のBSDホスト導入に影響するMulticastに変更を説明しました。 さらに、IPv4ユニキャスト放送がマルチキャスト放送に取り替えられるように見えます。
4.4 Flow Specification and Handling
4.4 流れ仕様と取り扱い
This will be an extended capability proposed by all IPngs'.
'これはすべてのIPngsによって提案された拡張能力になるでしょう'。
4.5 System Discovery
4.5 システム発見
Each proposal has depicted a new model for IPng system discovery of a host.
各提案はホストのIPngシステム発見のために新しいモデルについて表現しました。
4.6 Translation and Encapsulation
4.6 翻訳とカプセル化
The routing abstraction in a BSD host will have to deal with the affect of any translation or encapsulation of network layer datagrams, if they are required by an IPng.
BSDホストでのルーティング抽象化はどんな翻訳の感情かネットワーク層データグラムのカプセル化にも対処しなければならないでしょう、それらがIPngによって必要とされるなら。
4.7 Network Layer Security
4.7 ネットワーク層セキュリティ
It is perceived that network layer security will be required at the network layer component of IPng and this will have to be implemented by a BSD host.
ネットワーク層セキュリティがIPngのネットワーク層の部品で必要であると知覚されて、これはBSDホストによって実装されなければならないでしょう。
4.8 Socket Address Structure
4.8 ソケットアドレス構造
The network kernel socket address structure will change because of IPng.
ネットワークカーネルソケットアドレス構造はIPngのために変化するでしょう。
4.9 Network APIs
4.9 ネットワークAPI
The network APIs for a BSD host will have to be enhanced to support IPng. In addition any new options available to the applications because of the IPng network service will have to be added as an option to the APIs.
BSDホストのためのネットワークAPIは、IPngをサポートするために高められなければならないでしょう。 さらに、IPngネットワーク・サービスのためにアプリケーションに利用可能などんな新しいオプションもオプションとしてAPIに加えられなければならないでしょう。
Bound [Page 8] RFC 1682 IPng BSD Host Implementation Analysis August 1994
制限された[8ページ]RFC1682IPng BSDは1994年8月に実装分析を主催します。
4.10 Network Management
4.10 ネットワークマネージメント
Network management for IPng will have to support new network objects as defined by the IPng proposal. In addition the data structures in the BSD host network kernel used as information to display network topology will be altered by a new network layer datagram and associated components.
IPngのためのネットワークマネージメントはIPng提案で定義されるように新しいネットワークオブジェクトを支えなければならないでしょう。 さらに、ネットワーク形態を表示するのに情報として使用されるBSDホストネットワークカーネルにおけるデータ構造は新しいネットワーク層データグラムと関連コンポーネントによって変更されるでしょう。
5. Transition Software
5. 変遷ソフトウェア
Transition software in this white paper references the network software alterations on a host to support both IPv4 and IPng for applications and the hosts operating system network kernel. It is the subject of another set of papers to identify the transition software required by network managers to transition their users from IPv4 to IPng.
この白書の変遷ソフトウェアは、両方がアプリケーションのためのIPv4とIPngとホストオペレーティングシステムネットワークカーネルであるとサポートするためにホストの上でネットワークソフトウェア変更に参照をつけます。 変遷ソフトウェアを特定するもう1セットの書類の対象がネットワークマネージャでIPv4からIPngまで彼らのユーザを変遷に必要としたということです。
Transition software on a host will be required to maintain compatibility between IPv4 and IPng, and to manage both the existing IPv4 and IPng environments as follows:
ホストの上の変遷ソフトウェアがIPv4とIPngとの互換性を維持して、既存のIPv4と以下のIPng環境の両方を管理するのに必要でしょう:
1. BIND DNS record updates and handling by the application.
2. SNMP management interface and monitoring of host network
structures.
3. APIs supporting IPv4 and IPng differentiation for the
application.
4. Defacto network tools altered (e.g., tcpdump, traceroute,
netstat).
5. ARP to new system discovery.
6. BOOTP diskless node support for IPng.
7. DHCP integration with IPng Autoconfiguration.
8. Routing table configuration on the BSD host (e.g., routed,
ifconfig).
9. Selection of the network layer (IPv4 or IPng) at the
transport layer.
10. New options and services provided by an IPng protocol.
11. IPv4 and IPng routing protocols in the network layer.
12. IPv4 and IPng system discovery in the network layer.
1. BIND DNSはアプリケーションでアップデートと取り扱いを記録します。 2. ホストネットワーク構造のSNMP管理インタフェースとモニター。 3. IPv4とIPngがアプリケーションのための分化であるとサポートするAPI。 4. 事実上のネットワークツールは(例えば、tcpdump、トレースルート、netstat)を変更しました。 5. 新しいシステム発見へのARP。 6. IPngのBOOTPのディスクレスノードサポート。 7. IPng AutoconfigurationとのDHCP統合。 8. BSDホスト(例えば、ifconfigに、掘る)の上でテーブル構成を発送します。 9. トランスポート層のネットワーク層(IPv4かIPng)の選択。 10. IPngによって提供された新しいオプションとサービスは議定書を作ります。 11. ネットワーク層におけるIPv4とIPngルーティング・プロトコル。 12. ネットワーク層におけるIPv4とIPngシステム発見。
These are only the highlights of the transition software that a host will have to deal with in its implementation of IPng. The host network architecture diagram depicted previously will require software enhancements to each label in the diagram.
唯一のこれらはホストがIPngの実装で対処しなければならない変遷ソフトウェアに関するハイライトです。 以前に表現されたホストネットワークアーキテクチャダイヤグラムはダイヤグラムによる各ラベルにソフトウェア機能強化を必要とするでしょう。
It is very important that each IPng proposal provide a specification for a transition plan from IPv4 to IPng and their technical criteria for the interoperation between IPv4 and IPng.
それぞれのIPng提案がIPv4からIPngまでの変遷プランとそれらのIPv4とIPngの間のinteroperationの技術的な評価基準のための仕様を提供するのは、非常に重要です。
Bound [Page 9] RFC 1682 IPng BSD Host Implementation Analysis August 1994
制限された[9ページ]RFC1682IPng BSDは1994年8月に実装分析を主催します。
It should also be a requirement that existing IPv4 applications not have to be recompiled when a host has implemented both an IPv4 and an IPng network layer and associated components.
また、それはホストが、両方がIPv4と、IPngネットワーク層と関連コンポーネントであると実装したとき、既存のIPv4アプリケーションが再コンパイルされる必要はないという要件であるべきです。
It is very desirable that when a host implements both an IPv4 and an IPng network layer and associated components that there is no performance degradation on the host compared to the performance of an existing IPv4 only host.
ホストが、ホストの上でIPv4とIPngネットワーク層とある関連コンポーネントの両方が性能退行でないと実装するとき、それがIPv4が接待するだけである存在の性能と比較されたのは、非常に望ましいです。
It should not be a requirement by IPng that a host must support both an IPv4 and an IPng network layer.
それはIPngによるホストが、両方がIPv4とIPngネットワーク層であるとサポートしなければならないという要件であるはずがありません。
6. A Deployment Consideration
6. 展開の考慮
Complete and extensive technical specifications must be available for any IPng proposal, and a selection of any proposal must accommodate multiple implementations. The IPng Directorate should review proposed specifications for completeness.
完全で大規模な技術仕様書はどんなIPng提案にも利用可能であるに違いありません、そして、どんな提案の選択も複数の実装を収容しなければなりません。 IPng Directorateは完全性のための提案された仕様を再検討するはずです。
It is important that the IPng Directorate determine how long the CIDR IPv4 address plan can extend the life of IPv4 addresses on the Internet. This variable can affect the time we have to deploy IPng and the proposed transition plans.
IPng Directorateが、CIDR IPv4アドレスプランがどれくらい長い間インターネットにおけるIPv4アドレスの寿命を伸ばすことができるかを決定するのは、重要です。 この変数は私たちがIPngと提案された変遷がプランであると配布しなければならない時に影響できます。
References
参照
[1] Gilligan, B., et. al., "IPAE: The SIPP Interoperability and
Transition Mechanism", Work in Progress.
[1] etギリガン、B.、アル、「IPAE:」 「SIPP相互運用性と変遷メカニズム」は進行中で働いています。
[2] Piscitello, D., "FTP Operation Over Big Address Records
(FOOBAR)", RFC 1639, Core Competence, Inc., June 1994.
[2]Piscitello、D.、「大きいアドレス記録(FOOBAR)の上のFTP操作」、RFC1639、コアコンピタンスInc.、1994年6月。
Security Considerations
セキュリティ問題
Security issues are discussed in Section 4.7.
セクション4.7で安全保障問題について議論します。
Author's Address
作者のアドレス
Jim Bound Digital Equipment Corporation 110 Spitbrook Road ZK3-3/U14 Nashua, NH 03062-2698
ジム・制限されたDEC110Spitbrook道路ZK3-3/U14ナッシュア、ニューハンプシャー03062-2698
Phone: +1 603 881 0400 EMail: bound@zk3.dec.com
以下に電話をしてください。 +1 0400年の603 881メール: bound@zk3.dec.com
Bound [Page 10]
縛られます。[10ページ]
一覧
スポンサーリンク
