RFC1118 日本語訳
1118 Hitchhikers guide to the Internet. E. Krol. September 1989. (Format: TXT=62757 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group E. Krol
Request for Comments: 1118 University of Illinois Urbana
September 1989
コメントを求めるワーキンググループE.クロールの要求をネットワークでつないでください: 1118 イリノイアーバナ1989年9月の大学
The Hitchhikers Guide to the Internet
インターネットへのヒッチハイカーガイド
Status of this Memo
このMemoの状態
This RFC is being distributed to members of the Internet community in order to make available some "hints" which will allow new network participants to understand how the direction of the Internet is set, how to acquire online information and how to be a good Internet neighbor. While the information discussed may not be relevant to the research problems of the Internet, it may be interesting to a number of researchers and implementors. No standards are defined or specified in this memo. Distribution of this memo is unlimited.
このRFCは新しいネットワーク関係者が、インターネットの方向性がどのように設定されるかを理解できるいくつかの「ヒント」を利用可能にするようにインターネットコミュニティのメンバーに分配されています、オンライン情報とどう良いインターネット隣人であるかを取得する方法。 議論した情報がインターネットの研究課題に関連していないかもしれない間、多くの研究者と作成者にとって、それはおもしろいかもしれません。 規格は、全くこのメモで定義もされませんし、指定もされません。 このメモの分配は無制限です。
NOTICE:
通知:
The hitchhikers guide to the Internet is a very unevenly edited memo and contains many passages which simply seemed to its editors like a good idea at the time. It is an indispensable companion to all those who are keen to make sense of life in an infinitely complex and confusing Internet, for although it cannot hope to be useful or informative on all matters, it does make the reassuring claim that where it is inaccurate, it is at least definitively inaccurate. In cases of major discrepancy it is always reality that's got it wrong. And remember, DON'T PANIC. (Apologies to Douglas Adams.)
インターネットへのヒッチハイカーガイドは、非常に不規則に編集されたメモであり、当時名案のようにエディタにとって単に見えた多くの通路を含みます。 それはすべての無限に複雑で紛らわしいインターネットの人生を理解できることを切望しているそれらへのなくてはならない友です、いっさいの事項について役に立つか、または有益であることを望むことができませんが、それが不正確であるところで少なくとも決定的に不正確であるという心強いクレームを不正確にするので。 主要な食い違いの場合では、いつもそれはそれを間違っていた現実です。 DON'T PANIC、そして、覚えていてください。 (ダグラス・アダムスへの謝罪。)
Purpose and Audience
目的と聴衆
This document assumes that one is familiar with the workings of a non-connected simple IP network (e.g., a few 4.3 BSD systems on an Ethernet not connected to anywhere else). Appendix A contains remedial information to get one to this point. Its purpose is to get that person, familiar with a simple net, versed in the "oral tradition" of the Internet to the point that that net can be connected to the Internet with little danger to either. It is not a tutorial, it consists of pointers to other places, literature, and hints which are not normally documented. Since the Internet is a dynamic environment, changes to this document will be made regularly. The author welcomes comments and suggestions. This is especially true of terms for the glossary (definitions are not necessary).
このドキュメントは、1つが非接続された簡単なIPネットワークの作業になじみ深いと仮定します(イーサネットの例えばいくつかの4.3台のBSDシステムは他のどこかに接続しませんでした)。 付録Aは1つをこの位まで得る補修の情報を含んでいます。 目的はインターネットの「口頭の伝統」で危険でほとんどそのネットをインターネットに関連づけることができないというポイントにその簡単なネットに詳しい人のどちらかに作詩をさせることです。 チュートリアルでない、それは通常、記録されない他の場所、文学、およびヒントにポインタから成ります。 インターネットが動的環境であるので、このドキュメントへの変更は定期的に行われるでしょう。 作者はコメントと提案を歓迎します。 これは用語集のための用語に関して特に本当です(定義は必要ではありません)。
Krol [Page 1] RFC 1118 The Hitchhikers Guide to the Internet September 1989
ヒッチハイカーが1989年9月にインターネットに誘導するクロール[1ページ]RFC1118
What is the Internet?
インターネットは何ですか?
In the beginning there was the ARPANET, a wide area experimental network connecting hosts and terminal servers together. Procedures were set up to regulate the allocation of addresses and to create voluntary standards for the network. As local area networks became more pervasive, many hosts became gateways to local networks. A network layer to allow the interoperation of these networks was developed and called Internet Protocol (IP). Over time other groups created long haul IP based networks (NASA, NSF, states...). These nets, too, interoperate because of IP. The collection of all of these interoperating networks is the Internet.
初めに、アルパネット、ホストに接する広い領域実験的なネットワーク、および端末のサーバが一緒にありました。 処置は、アドレスの配分を規制して、ネットワークのために自主基準を作成するために確立されていました。 ローカル・エリア・ネットワークが、より普及するようになったとき、多くのホストが企業内情報通信網へのゲートウェイになりました。 これらのネットワークのinteroperationを許容するネットワーク層は、インターネットプロトコル(IP)と開発されて、呼ばれました。 時間がたつにつれて、他のグループは長期のIPのベースのネットワークを創設しました(NASA(NSF)は…を述べます)。 また、これらのネットはIPのために共同利用します。 ネットワークを共同利用するこれらのすべての収集はインターネットです。
A few groups provide much of the information services on the Internet. Information Sciences Institute (ISI) does much of the standardization and allocation work of the Internet acting as the Internet Assigned Numbers Authority (IANA). SRI International provides the principal information services for the Internet by operating the Network Information Center (NIC). In fact, after you are connected to the Internet most of the information in this document can be retrieved from the SRI-NIC. Bolt Beranek and Newman (BBN) provides information services for CSNET (the CIC) and NSFNET (the NNSC), and Merit provides information services for NSFNET (the NIS).
いくつかのグループがインターネットの情報サービスの多くを提供します。 Sciences Institute(ISI)がたくさんする標準化に関する情報とインターネットAssigned民数記Authority(IANA)として機能するインターネットの配分仕事。 SRIインターナショナルは、Networkインフォメーション・センター(NIC)を経営することによって、主要な情報サービスをインターネットに提供します。 事実上、あなたがインターネットに接続された後にSRI-NICから情報の大部分を本書では検索できます。 Beranekをボルトで締めて、ニューマン(BBN)はCSNET(CIC)とNSFNET(NNSC)に情報サービスを供給します、そして、MeritはNSFNET(NIS)に情報サービスを供給します。
Operating the Internet
インターネットを操作します。
Each network, be it the ARPANET, NSFNET or a regional network, has its own operations center. The ARPANET is run by BBN, Inc. under contract from DCA (on behalf of DARPA). Their facility is called the Network Operations Center or NOC. Merit, Inc. operates NSFNET from yet another and completely seperate NOC. It goes on to the regionals having similar facilities to monitor and keep watch over the goings on of their portion of the Internet. In addition, they all should have some knowledge of what is happening to the Internet in total. If a problem comes up, it is suggested that a campus network liaison should contact the network operator to which he is directly connected. That is, if you are connected to a regional network (which is gatewayed to the NSFNET, which is connected to the ARPANET...) and have a problem, you should contact your regional network operations center.
それぞれ、アルパネット(NSFNETか地域ネットワーク)にそれ自身の操作センターがあるか否かに関係なく、ネットワークでつなぎます。 BBN Inc.はDCA(DARPAを代表した)からの契約に基づきアルパネットを走らせます。 それらの施設はネットワーク運営センターかNOCと呼ばれます。 長所Inc.はしかし、別のものと完全にseperate NOCからNSFNETを運用します。 それは、それらのインターネットの部分でオンな行くことの上に腕時計をモニターして、保つために同様の施設を持っている地方版に進んでいます。 さらに、彼らには皆、合計でインターネットがどうなるかに関する何らかの知識があるべきです。 問題が来るなら、キャンパスネットワーク連絡係が彼が直接接続されるネットワーク・オペレータに連絡するべきであると示唆されます。 すなわち、地域ネットワーク(アルパネットに…接続されるNSFNETにgatewayedされる)に関連づけられて、問題がありましたら、あなたは地域ネットワーク操作センターに接触するべきです。
RFCs
RFCs
The internal workings of the Internet are defined by a set of documents called RFCs (Request for Comments). The general process for creating an RFC is for someone wanting something formalized to write a document describing the issue and mailing it to Jon Postel
インターネットの内部の作業はRFCs(Commentsのために、要求する)と呼ばれる1セットのドキュメントによって定義されます。 RFCを作成するための一般的な過程は問題について説明して、ジョン・ポステルにそれを郵送しながらドキュメントを書くために何かを正式にして欲しいだれかのためのものです。
Krol [Page 2] RFC 1118 The Hitchhikers Guide to the Internet September 1989
ヒッチハイカーが1989年9月にインターネットに誘導するクロール[2ページ]RFC1118
(Postel@ISI.EDU). He acts as a referee for the proposal. It is then commented upon by all those wishing to take part in the discussion (electronically of course). It may go through multiple revisions. Should it be generally accepted as a good idea, it will be assigned a number and filed with the RFCs.
( Postel@ISI.EDU 。) 彼は提案のためのレフリーとして務めます。 次に、それが議論に参加したがっているすべてのものが批評される、(電子的である、もちろん) それは複数の改正に直面するかもしれません。 名案として一般に認められると、それは、数が割り当てられて、RFCsと共にファイルされるでしょう。
There are two independent categorizations of protocols. The first is the state of standardization which is one of "standard", "draft standard", "proposed", "experimental", or "historic". The second is the status of this protocol which is one of "required", "recommended", "elective", or "not recommended". One could expect a particular protocol to move along the scale of status from elective to required at the same time as it moves along the scale of standardization from proposed to standard.
プロトコルの2つの独立している分類があります。 1番目は1である「提案された」か、「実験的である」か、「歴史的な」「標準」の「草稿規格」の標準化の状態です。 「推薦されない」で、2番目は1である「必要で」、「お勧め」の「選択科目」のこのプロトコルの状態です。 人は、状態のスケールに沿って選択科目から動く特定のプロトコルがそれと同時に提案されるのから規格までの標準化のスケールに沿って移動を必要としたと予想できました。
A Required Standard protocol (e.g., RFC-791, The Internet Protocol) must be implemented on any host connected to the Internet. Recommended Standard protocols are generally implemented by network hosts. Lack of them does not preclude access to the Internet, but may impact its usability. RFC-793 (Transmission Control Protocol) is a Recommended Standard protocol. Elective Proposed protocols were discussed and agreed to, but their application has never come into wide use. This may be due to the lack of wide need for the specific application (RFC-937, The Post Office Protocol) or that, although technically superior, ran against other pervasive approaches. It is suggested that should the facility be required by a particular site, an implementation be done in accordance with the RFC. This insures that, should the idea be one whose time has come, the implementation will be in accordance with some standard and will be generally usable.
インターネットに接続されたどんなホストの上でもRequired Standardプロトコル(例えば、RFC-791、インターネットプロトコル)を実行しなければなりません。 一般に、お勧めのStandardプロトコルはネットワークホストによって実行されます。 それらの不足は、インターネットへのアクセスを排除しませんが、ユーザビリティに影響を与えるかもしれません。 RFC-793(通信制御プロトコル)はRecommended Standardプロトコルです。 選挙のProposedプロトコルは、議論して、議論するのに同意しましたが、彼らのアプリケーションは一度も普及したことがありません。 それは、これが特定のアプリケーション(RFC-937、ポスト紙オフィスプロトコル)の広い必要性の不足のためであったかもしれませんか技術的に優れていますが、他の普及しているアプローチにぶつかりました。 特定のサイト、実現で施設を必要とするべきです。それが示される、それ、RFCによると、します。 これは実現が考えが時間が来たものであるなら何らかの規格に従ってあって、一般に、使用可能になるのを保障します。
Informational RFCs contain factual information about the Internet and its operation (RFC-1010, Assigned Numbers). Finally, as the Internet and technology have grown, some RFCs have become unnecessary. These obsolete RFCs cannot be ignored, however. Frequently when a change is made to some RFC that causes a new one to be issued obsoleting others, the new RFC may only contains explanations and motivations for the change. Understanding the model on which the whole facility is based may involve reading the original and subsequent RFCs on the topic. (Appendix B contains a list of what are considered to be the major RFCs necessary for understanding the Internet).
情報のRFCsはインターネットとその操作(RFC-1010、Assigned民数記)の事実上の情報を含んでいます。 最終的に、インターネットと技術が発展するのに従って、いくつかのRFCsが不要になりました。 しかしながら、これらの時代遅れのRFCsを無視できません。変更を新しいものを発行させるいくらかのRFCにするときだけ、頻繁に、他のもの、新しいRFCがそうする時代遅れには変化に関する説明と動機を含んでいます。 全体の施設が基づいているモデルを理解しているのは、話題に関してオリジナルの、そして、その後のRFCsを読むことを伴うかもしれません。 (付録Bは何がインターネットを理解するのに必要な主要なRFCsであると考えられるかに関するリストを含んでいます。)
Only a few RFCs actually specify standards, most RFCs are for information or discussion purposes. To find out what the current standards are see the RFC titled "IAB Official Protocol Standards" (most recently published as RFC-1100).
ほんのいくつかのRFCsが実際に規格を指定して、ほとんどのRFCsが情報か議論目的のためのものです。 現在の規格が何であるかを見つけるには、RFCが「IABの公式のプロトコル標準」(ごく最近、RFC-1100として発行される)と題をつけられるのを見てください。
Krol [Page 3] RFC 1118 The Hitchhikers Guide to the Internet September 1989
ヒッチハイカーが1989年9月にインターネットに誘導するクロール[3ページ]RFC1118
The Network Information Center (NIC)
ネットワークインフォメーション・センター(NIC)
The NIC is a facility available to all Internet users which provides information to the community. There are three means of NIC contact: network, telephone, and mail. The network accesses are the most prevalent. Interactive access is frequently used to do queries of NIC service overviews, look up user and host names, and scan lists of NIC documents. It is available by using
NICはすべてのインターネットユーザにとって、利用可能な施設です(情報を共同体に提供します)。 NIC接触の3つの手段があります: ネットワークでつないで、電話をして、郵送します。 ネットワークアクセスは最も一般的です。 対話的なアクセスは、NICサービス概観の質問をして、ユーザとホスト名を訪ねて、NICドキュメントのリストをスキャンするのに頻繁に使用されます。 それは、使用することによって、利用可能です。
%telnet nic.ddn.mil
%telnet nic.ddn.mil
on a BSD system, and following the directions provided by a user friendly prompter. From poking around in the databases provided, one might decide that a document named NETINFO:NUG.DOC (The Users Guide to the ARPANET) would be worth having. It could be retrieved via an anonymous FTP. An anonymous FTP would proceed something like the following. (The dialogue may vary slightly depending on the implementation of FTP you are using).
BSDシステムと、ユーザフレンドリーなプロンプタによって提供された指示に従うことに関して。 提供されたデータベースでせんさくするので、人は、ドキュメントがNETINFOを命名したと決めるかもしれません: NUG.DOC(アルパネットへのUsersガイド)は持つ価値があるでしょう。 公開FTPでそれを検索できるでしょう。 公開FTPは以下のように続くでしょう。 (あなたが使用しているFTPの実現によって、対話はわずかに変わるかもしれません。)
%ftp nic.ddn.mil
Connected to nic.ddn.mil
220 NIC.DDN.MIL FTP Server 5Z(47)-6 at Wed 17-Jun-87 12:00 PDT
Name (nic.ddn.mil:myname): anonymous
331 ANONYMOUS user ok, send real ident as password.
Password: myname
230 User ANONYMOUS logged in at Wed 17-Jun-87 12:01 PDT, job 15.
ftp> get netinfo:nug.doc
200 Port 18.144 at host 128.174.5.50 accepted.
150 ASCII retrieve of <NETINFO>NUG.DOC.11 started.
226 Transfer Completed 157675 (8) bytes transferred
local: netinfo:nug.doc remote:netinfo:nug.doc
157675 bytes in 4.5e+02 seconds (0.34 Kbytes/s)
ftp> quit
221 QUIT command received. Goodbye.
水曜日の1987年6月17日12時0分の太平洋夏時間のnic.ddn.mil220NIC.DDN.MIL FTP Server 5Z(47)-6への%ftp nic.ddn.mil Connected、Name(nic.ddn.mil: myname): 匿名の331更生会のユーザ、OK、パスワードとして本当のidentを送ってください。 パスワード: User更生会が太平洋夏時間の水曜日の1987年6月17日12時1分仕事15ftp>のときにログインしたmyname230はnetinfoを手に入れます: .50が受け入れたホスト128.174.5におけるnug.doc200Port18.144。 ASCIIが検索する150、<NETINFOでは、>NUG.DOC.11は始まりました。 226 転送Completed157675(8)バイトは地方で移されました: nug.docリモートな状態で以下をnetinfoする、: netinfo: 4.5e+02秒(0.34キロバイト/s)ftp>の157675バイトがやめるnug.docは受信されました221QUITが、命令する。 さようなら。
(Another good initial document to fetch is NETINFO:WHAT-THE-NIC- DOES.TXT).
(別の良い初期のドキュメント、フェッチには、NETINFO: WHAT NIC- DOES.TXTがある、)
Questions of the NIC or problems with services can be asked of or reported to using electronic mail. The following addresses can be used:
サービスに関するNICか問題の質問は、電子メールを尋ねるか、または使用に報告できます。 以下のアドレスを使用できます:
NIC@NIC.DDN.MIL General user assistance, document requests
REGISTRAR@NIC.DDN.MIL User registration and WHOIS updates
HOSTMASTER@NIC.DDN.MIL Hostname and domain changes and updates
ACTION@NIC.DDN.MIL SRI-NIC computer operations
SUGGESTIONS@NIC.DDN.MIL Comments on NIC publications and services
資料請求の NIC@NIC.DDN.MIL の一般ユーザ支援、 REGISTRAR@NIC.DDN.MIL User登録、およびWHOISは HOSTMASTER@NIC.DDN.MIL Hostnameとドメイン変化をアップデートして、NIC刊行物とサービスのときに ACTION@NIC.DDN.MIL SRI-NICコンピュータ操作 SUGGESTIONS@NIC.DDN.MIL Commentsをアップデートします。
Krol [Page 4] RFC 1118 The Hitchhikers Guide to the Internet September 1989
ヒッチハイカーが1989年9月にインターネットに誘導するクロール[4ページ]RFC1118
For people without network access, or if the number of documents is large, many of the NIC documents are available in printed form for a small charge. One frequently ordered document for starting sites is a compendium of major RFCs. Telephone access is used primarily for questions or problems with network access. (See appendix B for mail/telephone contact numbers).
ネットワークアクセスのない人々かそれともドキュメントの数が大きいかどうかにおいて、NICドキュメントの多くが印刷された用紙でわずかな料金に利用可能です。 始めのサイトのための1通の頻繁に規則正しいドキュメントが主要なRFCsに関する概要です。 電話アクセスは主としてネットワークアクセサリーに関する質問か問題に使用されます。 (メール/電話連絡番号に関して付録Bを見ます。)
The NSFNET Network Service Center
NSFNETネットワーク・サービスセンター
The NSFNET Network Service Center (NNSC), located at BBN Systems and Technologies Corp., is a project of the University Corporation for Atmospheric Research under agreement with the National Science Foundation. The NNSC provides support to end-users of NSFNET should they have questions or encounter problems traversing the network.
BBN SystemsとTechnologies社に位置するNSFNET Network Serviceセンター(NNSC)は国立科学財団と協定での大気調査のための大学社のプロジェクトです。 彼らにネットワークを横断することにおける質問か遭遇問題があるなら、NNSCはNSFNETのエンドユーザにサポートを提供します。
The NNSC, which has information and documents online and in printed form, distributes news through network mailing lists, bulletins, and online reports. NNSC publications include a hardcopy newsletter, the NSF Network News, which contains articles of interest to network users and the Internet Resource Guide, which lists facilities (such as supercomputer centers and on-line library catalogues) accessible from the Internet. The Resource Guide can be obtained via anonymous ftp to nnsc.nsf.net in the directory resource-guide, or by joining the resource guide mailing list (send a subscription request to Resource-Guide-Request@NNSC.NSF.NET.)
NNSC(オンラインと印刷された用紙に情報とドキュメントを持っている)はネットワークメーリングリスト、報告、およびオンラインレポートを通してニュースを分配します。 NNSC刊行物はハードコピーニュースレター、ネットワーク利用者とインターネットからアクセスしやすい施設(スーパーコンピュータセンターやオンライン蔵書目録などの)を記載するインターネット資料ガイドにとって、興味深い記事を含むNSF Network Newsを含んでいます。 ディレクトリリソースガイド、またはリソースガイドメーリングリストを接合することによって、nnsc.nsf.netへのアノニマスFTPでResourceガイドを入手できます。(購読要求を Resource-Guide-Request@NNSC.NSF.NET に送ってください。)
Mail Reflectors
反射鏡を郵送してください。
The way most people keep up to date on network news is through subscription to a number of mail reflectors (also known as mail exploders). Mail reflectors are special electronic mailboxes which, when they receive a message, resend it to a list of other mailboxes. This in effect creates a discussion group on a particular topic. Each subscriber sees all the mail forwarded by the reflector, and if one wants to put his "two cents" in sends a message with the comments to the reflector.
ほとんどの人々がネットニュースの上を時代について行く道が多くのメール反射鏡(また、メール発破器として、知られている)の購読であります。 メール反射鏡は彼らがメッセージを受け取るとき他のメールボックスのリストにそれを再送する特別なメールボックスです。 事実上、これは特定の話題に関してディスカッション・グループを創設します。 各加入者は、反射鏡と人が彼の「2セント」を入れたがっているかどうかによって郵便配達人が進めたすべてがコメントと共にメッセージを反射鏡に送るのを見ます。
The general format to subscribe to a mail list is to find the address reflector and append the string -REQUEST to the mailbox name (not the host name). For example, if you wanted to take part in the mailing list for NSFNET reflected by NSFNET-INFO@MERIT.EDU, one sends a request to NSFNET-INFO-REQUEST@MERIT.EDU. This may be a wonderful scheme, but the problem is that you must know the list exists in the first place. It is suggested that, if you are interested, you read the mail from one list (like NSFNET-INFO) and you will probably become familiar with the existence of others. A registration service for mail reflectors is provided by the NIC in the files NETINFO:INTEREST-GROUPS-1.TXT, NETINFO:INTEREST-GROUPS-2.TXT,
メール・リストに申し込む一般形式は、メールボックス名(ホスト名でない)にアドレス反射鏡を見つけて、ストリング-REQUESTを追加することです。 例えば、あなたが NSFNET-INFO@MERIT.EDU によって反映されたNSFNETのためのメーリングリストに参加したかったなら、1つは要求を NSFNET-INFO-REQUEST@MERIT.EDU に送ります。 これは素晴らしい計画であるかもしれませんが、問題はあなたが、リストが第一に存在するのを知らなければならないということです。 関心があるならあなたが1つのリスト(NSFNET-INFOのような)からメールを読むことが提案されて、あなたはたぶん他のものの存在になじみ深くなるでしょう。 メール反射鏡のための登録サービスはNICによってNETINFO: NETINFO: ファイルINTEREST-GROUPS-1.TXT、INTEREST-GROUPS-2.TXTに提供されます。
Krol [Page 5] RFC 1118 The Hitchhikers Guide to the Internet September 1989
ヒッチハイカーが1989年9月にインターネットに誘導するクロール[5ページ]RFC1118
NETINFO:INTEREST-GROUPS-3.TXT, through NETINFO:INTEREST-GROUPS-9.TXT.
NETINFO: NETINFOを通して: 関心は3.TXTを分類して、関心は9.TXTを分類します。
The NSFNET-INFO mail reflector is targeted at those people who have a day to day interest in the news of the NSFNET (the backbone, regional network, and Internet inter-connection site workers). The messages are reflected by a central location and are sent as separate messages to each subscriber. This creates hundreds of messages on the wide area networks where bandwidth is the scarcest.
NSFNET-INFOメール反射鏡は1日から日に(背骨、地域ネットワーク、およびインターネット相互接続サイト労働者)をNSFNETに関するニュースに関心があらせる人々をターゲットにします。 メッセージを中心の位置で反映して、別々のメッセージとして各加入者に送ります。 これは帯域幅が最も不十分である広域ネットワークに関する何百ものメッセージを作成します。
There are two ways in which a campus could spread the news and not cause these messages to inundate the wide area networks. One is to re-reflect the message on the campus. That is, set up a reflector on a local machine which forwards the message to a campus distribution list. The other is to create an alias on a campus machine which places the messages into a notesfile on the topic. Campus users who want the information could access the notesfile and see the messages that have been sent since their last access. One might also elect to have the campus wide area network liaison screen the messages in either case and only forward those which are considered of merit. Either of these schemes allows one message to be sent to the campus, while allowing wide distribution within.
キャンパスがニュースを広げて、広域ネットワークを水浸しにするこれらのメッセージを引き起こさない場合があった2つの方法があります。 1つはキャンパスでメッセージを再反映することになっています。 キャンパス発送先リストにメッセージを転送する地方のマシンの上に反射鏡に設定されて、それはそうです。 もう片方は話題のnotesfileにメッセージを置くキャンパスマシンに別名を作成することです。 情報が欲しいキャンパスユーザは、notesfileにアクセスして、それらの最後のアクセサリー以来送られるメッセージを見ることができました。 また、人は、キャンパス広域ネットワーク連絡がどちらかのケースの中のメッセージを上映して、長所について考えられるものを進めるだけであるのを持っているのを選ぶかもしれません。 これらの計画のどちらかが中に広範な分布を許容している間、キャンパスに送られるべき1つのメッセージを許容します。
Address Allocation
アドレス配分
Before a local network can be connected to the Internet it must be allocated a unique IP address. These addresses are allocated by SRI-NIC. The allocation process consists of getting an application form. Send a message to Hostmaster@NIC.DDN.MIL and ask for the template for a connected address. This template is filled out and mailed back to the hostmaster. An address is allocated and e-mailed back to you. This can also be done by postal mail (Appendix B).
企業内情報通信網をインターネットに接続できる前に、固有のIPアドレスをそれに割り当てなければなりません。 これらのアドレスはSRI-NICによって割り当てられます。 割当過程は申込み書を手に入れるのから成ります。 メッセージを Hostmaster@NIC.DDN.MIL に送ってください、そして、接続アドレスのためにテンプレートを求めてください。 このテンプレートにhostmasterに書き込んで、郵送して戻します。 あなたにアドレスを割り当てて、メールして戻します。 また、郵便(付録B)でこれができます。
IP addresses are 32 bits long. It is usually written as four decimal numbers separated by periods (e.g., 192.17.5.100). Each number is the value of an octet of the 32 bits. Some networks might choose to organize themselves as very flat (one net with a lot of nodes) and some might organize hierarchically (many interconnected nets with fewer nodes each and a backbone). To provide for these cases, addresses were differentiated into class A, B, and C networks. This classification had to with the interpretation of the octets. Class A networks have the first octet as a network address and the remaining three as a host address on that network. Class C addresses have three octets of network address and one of host. Class B is split two and two. Therefore, there is an address space for a few large nets, a reasonable number of medium nets and a large number of small nets. The high order bits in the first octet are coded to tell the address format. There are very few unallocated class A nets, so a very good case must be made for them. So as a practical matter, one
IPアドレスは長さ32ビットです。 通常、それが周期的に切り離されている4つの10進数として書かれている、(例えば、192.17 .5 .100)。 各数は32ビットの八重奏の値です。 いくつかのネットワークが、非常に平坦(多くのノードがある1つのネット)として自分たちを組織化するのを選ぶかもしれません、そして、或るものは階層的で(それぞれより少ないノードとバックボーンがある多くのインタコネクトされたネット)を組織化するかもしれません。 これらのケースに備えるために、アドレスはクラスA、B、およびCネットワークに差別化されました。 この分類はそうしなければなりませんでした。八重奏の解釈で。 クラスAネットワークには、そのネットワークに関するホスト・アドレスとしてネットワーク・アドレスと残っている3としての最初の八重奏があります。 クラスCアドレスはネットワーク・アドレスと1の3つの八重奏をホストに持っています。 クラスBは分裂2とtwoです。 したがって、いくつかの大きいネット、相当な数の中くらいの正価、および多くの小さいネットのためのアドレス空間があります。 最初の八重奏における高位のビットは、アドレス形式を言うためにコード化されます。 ほんのわずかな「非-割り当て」られたクラスAネットがあるので、それらのために非常に良い弁護をしなければなりません。 したがって、実用的な件、1として
Krol [Page 6] RFC 1118 The Hitchhikers Guide to the Internet September 1989
ヒッチハイカーが1989年9月にインターネットに誘導するクロール[6ページ]RFC1118
has to choose between Class B and Class C when placing an order. (There are also class D (Multicast) and E (Experimental) formats. Multicast addresses will likely come into greater use in the near future, but are not frequently used yet).
注文をするとき、Class BとClass Cを選ぶために、持っています。 (クラスD(マルチキャスト)ともE(実験的)の形式があります。 マルチキャストアドレスは、近い将来おそらくより大きい使用に入りますが、まだ頻繁に使用されていません。).
In the past, sites requiring multiple network addresses requested multiple discrete addresses (usually Class C). This was done because much of the software available (notably 4.2BSD) could not deal with subnetted addresses. Information on how to reach a particular network (routing information) must be stored in Internet gateways and packet switches. Some of these nodes have a limited capability to store and exchange routing information (limited to about 700 networks). Therefore, it is suggested that any campus announce (make known to the Internet) no more than two discrete network numbers.
過去に、複数のネットワーク・アドレスを必要とするサイトが複数の離散的なアドレス(通常Class C)を要求しました。 利用可能なソフトウェア(著しく4.2BSD)の多くが「副-網で覆」われたアドレスに対処できなかったので、これをしました。 インターネット・ゲートウェイとパケット交換機にどう、特定のネットワーク(ルーティング情報)に達するかに関する情報を保存しなければなりません。 これらのいくつかのノードには、保存する限られた能力と交換ルーティング情報(およそ700のネットワークに制限される)があります。 したがって、どんなキャンパスも2つ未満の離散的なネットワーク・ナンバーを発表することが(インターネットに知らせます)提案されます。
If a campus expects to be constrained by this, it should consider subnetting. Subnetting (RFC-950) allows one to announce one address to the Internet and use a set of addresses on the campus. Basically, one defines a mask which allows the network to differentiate between the network portion and host portion of the address. By using a different mask on the Internet and the campus, the address can be interpreted in multiple ways. For example, if a campus requires two networks internally and has the 32,000 addresses beginning 128.174.X.X (a Class B address) allocated to it, the campus could allocate 128.174.5.X to one part of campus and 128.174.10.X to another. By advertising 128.174 to the Internet with a subnet mask of FF.FF.00.00, the Internet would treat these two addresses as one. Within the campus a mask of FF.FF.FF.00 would be used, allowing the campus to treat the addresses as separate entities. (In reality, you don't pass the subnet mask of FF.FF.00.00 to the Internet, the octet meaning is implicit in its being a class B address).
キャンパスが、これによって抑制されると予想するなら、それはサブネッティングを考えるべきです。 サブネッティング(RFC-950)は、1つのアドレスをインターネットに発表して、キャンパスで1セットのアドレスを使用するために1つを許容します。 基本的に、人はネットワークがネットワーク部分とアドレスのホスト部分を区別できるマスクを定義します。 インターネットとキャンパスで異なったマスクを使用することによって、複数の方法でアドレスを解釈できます。 例えば、キャンパスが内面的に2つのネットワークを必要として、それに割り当てられた128.174.X.X(Class Bアドレス)を始める3万2000のアドレスを持っているなら、キャンパスはキャンパスの一部への128.174.5.Xと別のものへの128.174.10.Xを割り当てるかもしれません。 FF.FFのサブネットマスクがあるインターネットへの広告128.174、.00、.00、インターネットはこれらの2つのアドレスを1つとして扱うでしょう。 キャンパスの中では、キャンパスが別々の実体としてアドレスを扱うのを許容して、FF.FF.FF.00のマスクは使用されるでしょう。 (ほんとうは、あなたがFF.FFのサブネットマスクを渡さない、.00、.00、インターネットに、八重奏意味がそれがクラスBアドレスであることで暗黙である、)
A word of warning is necessary. Not all systems know how to do subnetting. Some 4.2BSD systems require additional software. 4.3BSD systems subnet as released. Other devices and operating systems vary in the problems they have dealing with subnets. Frequently, these machines can be used as a leaf on a network but not as a gateway within the subnetted portion of the network. As time passes and more systems become 4.3BSD based, these problems should disappear.
戒めの言葉が必要です。 すべてのシステムがサブネッティングをする方法を知っているというわけではありません。 いくつかの4.2BSDシステムが付加ソフトウェアを必要とします。 リリースされるとしての4.3BSDシステムサブネット。 対向機器とオペレーティングシステムはサブネットに対処することにおけるそれらが持っている問題において異なります。 ネットワークの「副-網で覆」われた部分の中で頻繁に、これらのマシンは葉としてネットワークで使用されますが、ゲートウェイとして使用できません。 時間が経過して、より多くのシステムが基づく4.3BSDになるとき、これらの問題は見えなくなるべきです。
There has been some confusion in the past over the format of an IP broadcast address. Some machines used an address of all zeros to mean broadcast and some all ones. This was confusing when machines of both type were connected to the same network. The broadcast address of all ones has been adopted to end the grief. Some systems (e.g., 4.3 BSD) allow one to choose the format of the broadcast address. If a system does allow this choice, care should be taken that the all ones format is chosen. (This is explained in RFC-1009
過去の何らかの混乱がIP放送演説の形式でありました。 いくつかのマシンが放送することを意味するのにすべてのゼロのアドレスを使用しました、そして、何かがすべてのものを使用しました。 これによる両方のマシンがタイプされると混乱させることが同じネットワークに関連づけられたということでした。 すべてのものの放送演説は、深い悲しみを終わらせるために採用されました。 いくつかのシステム(例えば、4.3BSD)で、人は放送演説の形式を選ぶことができます。 システムがこの選択を許すなら、注意するべきである、それ、すべてのもの形式が選ばれています。 (これはRFC-1009で説明されます。
Krol [Page 7] RFC 1118 The Hitchhikers Guide to the Internet September 1989
ヒッチハイカーが1989年9月にインターネットに誘導するクロール[7ページ]RFC1118
and RFC-1010).
RFC-1010)
Internet Problems
インターネット問題
There are a number of problems with the Internet. Solutions to the problems range from software changes to long term research projects. Some of the major ones are detailed below:
インターネットに関する多くの問題があります。 問題の解決は長期研究計画へのソフトウェア変化から変化します。 主要なもののいくつかが以下で詳細です:
Number of Networks
ネットワークの数
When the Internet was designed it was to have about 50 connected
networks. With the explosion of networking, the number is now
approaching 1000. The software in a group of critical gateways
(called the core gateways) are not able to pass or store much more
than that number. In the short term, core reallocation and
recoding has raised the number slightly.
インターネットが設計されたとき、それには、およそ50の接続ネットワークがあることになっていました。 ネットワークの爆発で、数はもう、1000にアプローチしています。 重要なゲートウェイ(コアゲートウェイと呼ばれる)のグループにおけるソフトウェアはパスか店にその数よりはるかにできません。 短期間、コア再配分、および再コード化では、数をわずかに上げました。
Routing Issues
ルート設定問題
Along with sheer mass of the data necessary to route packets to a
large number of networks, there are many problems with the
updating, stability, and optimality of the routing algorithms.
Much research is being done in the area, but the optimal solution
to these routing problems is still years away. In most cases, the
the routing we have today works, but sub-optimally and sometimes
unpredictably. The current best hope for a good routing protocol
is something known as OSPFIGP which will be generally available
from many router manufacturers within a year.
多くのネットワークにパケットを発送するのに必要なデータの全くの固まりと共に、ルーティング・アルゴリズムのアップデート、安定性、および最適に関する多くの問題があります。その領域で多くの研究をしていますが、これらのルーティング問題の最適解がまだ何年も後にあります。 多くの場合、しかし、私たちが今日持っているルーティングはサブ最適に時々予想外に利きます。 1年以内に良いルーティング・プロトコルの現在の最も良い望みは一般に、多くのルータメーカーから利用可能になるOSPFIGPとして知られている何かです。
Trust Issues
信頼問題
Gateways exchange network routing information. Currently, most
gateways accept on faith that the information provided about the
state of the network is correct. In the past this was not a big
problem since most of the gateways belonged to a single
administrative entity (DARPA). Now, with multiple wide area
networks under different administrations, a rogue gateway
somewhere in the net could cripple the Internet. There is design
work going on to solve both the problem of a gateway doing
unreasonable things and providing enough information to reasonably
route data between multiply connected networks (multi-homed
networks).
ゲートウェイはネットワークルーティング情報を交換します。 現在、ほとんどのゲートウェイがネットワークの事情に関して提供された情報が正しいという信頼で受け入れます。 ゲートウェイの大部分がただ一つの管理実体に属したので、過去に、これは重要な問題(DARPA)ではありませんでした。 今、異なった政権での複数の広域ネットワークで、ネットにおけるどこかの凶暴なゲートウェイはインターネットを無力にするかもしれません。 ゲートウェイが無理なことをするという問題と合理的に多重連結のネットワークの間にデータを発送できるくらいの提供している情報の両方を解決し続けるデザインワークがある、(マルチ、家へ帰り、ネットワーク)
Capacity & Congestion
容量と混雑
Some portions of the Internet are very congested during the busy
part of the day. Growth is dramatic with some networks
experiencing growth in traffic in excess of 20% per month.
インターネットの数個の部分が1日の忙しい部分の間、非常に混雑しています。 いくつかのネットワークが1カ月あたり20%を超えてトラフィックにおける成長を経験していて、成長は劇的です。
Krol [Page 8] RFC 1118 The Hitchhikers Guide to the Internet September 1989
ヒッチハイカーが1989年9月にインターネットに誘導するクロール[8ページ]RFC1118
Additional bandwidth is planned, but delivery and budgets might
not allow supply to keep up.
追加帯域幅は計画されていますが、配送と予算で、供給は続けられないかもしれません。
Setting Direction and Priority
方向と優先権を設定します。
The Internet Activities Board (IAB), currently chaired by Vint Cerf of NRI, is responsible for setting the technical direction, establishing standards, and resolving problems in the Internet.
現在NRIのVintサーフによってまとめられたインターネットActivities Board(IAB)は技術的な方向を設定するのに責任があります、インターネットで基準を定めて、問題を解決して。
The current IAB members are:
現在のIABメンバーは以下の通りです。
Vinton Cerf - Chairman
David Clark - IRTF Chairman
Phillip Gross - IETF Chairman
Jon Postel - RFC Editor
Robert Braden - Executive Director
Hans-Werner Braun - NSFNET Liaison
Barry Leiner - CCIRN Liaison
Daniel Lynch - Vendor Liaison
Stephen Kent - Internet Security
ビントン・サーフ--デヴィッド・クラーク議長--IRTFのフィリップ議長のグロス--IETFジョン・ポステル議長--RFCエディタのロバート・ブレーデン--ヴェルナーハンス-専務のブラウン--NSFNET連絡バリトンサックスLeiner--CCIRN連絡のダニエル・リンチ--ベンダー連絡スティーブン・ケント--インターネットセキュリティ
This board is supported by a Research Task Force (chaired by Dave Clark of MIT) and an Engineering Task Force (chaired by Phill Gross of NRI).
このボードはResearch Task Force(MITのデーブ・クラークによってまとめられる)とEngineering Task Force(NRIのフィルGrossによってまとめられる)によって支えられます。
The Internet Research Task Force has the following Research Groups:
インターネットResearch Task Forceには、以下のResearch Groupsがあります:
Autonomous Networks Deborah Estrin
End-to-End Services Bob Braden
Privacy Steve Kent
User Interfaces Keith Lantz
自治のネットワークデボラEstrin終わりから終わりへのサービスボブブレーデンプライバシースティーブ・ケントユーザインタフェースキース・ランツ
The Internet Engineering Task Force has the following technical areas:
インターネット・エンジニアリング・タスク・フォースには、以下のテクニカルエリアがあります:
Applications TBD
Host Protocols Craig Partridge
Internet Protocols Noel Chiappa
Routing Robert Hinden
Network Management David Crocker
OSI Interoperability Ross Callon, Robert Hagen
Operations TBD
Security TBD
アプリケーションTBDホストプロトコルクレイグヤマウズラインターネットプロトコルクリスマスChiappaルート設定ロバートHindenネットワークマネージメントデヴィッド医者OSI相互運用性ロスCallon、ロバート・ハーゲン操作TBDセキュリティTBD
The Internet Engineering Task Force has the following Working Groups:
インターネット・エンジニアリング・タスク・フォースには、以下のWorking Groupsがあります:
ALERTMAN Louis Steinberg
Authentication Jeff Schiller
ALERTMANルイス・スタインバーグ・認証ジェフ・シラー
Krol [Page 9] RFC 1118 The Hitchhikers Guide to the Internet September 1989
ヒッチハイカーが1989年9月にインターネットに誘導するクロール[9ページ]RFC1118
CMIP over TCP Lee LaBarre
Domain Names Paul Mockapetris
Dynamic Host Config Ralph Droms
Host Requirements Bob Braden
Interconnectivity Guy Almes
Internet MIB Craig Partridge
Joint Management Susan Hares
LAN Mgr MIB Amatzia Ben-Artzi
NISI Karen Bowers
NM Serial Interface Jeff Case
NOC Tools Bob Enger
OSPF Mike Petry
Open Systems Routing Marianne Lepp
OSI Interoperability Ross Callon
PDN Routing Group CH Rokitansky
Performance and CC Allison Mankin
Point - Point IP Drew Perkins
ST and CO-IP Claudio Topolcic
Telnet Dave Borman
User Documents Karen Roubicek
User Services Karen Bowers
TCPリーLaBarreドメイン名ポールMockapetris動力の上のCMIPはコンフィグラルフDromsホスト要件ボブブレーデン相互接続性奴のAlmesインターネットMIBクレイグヤマウズラ合弁スーザン野兎のLAN Mgr MIB Amatziaベン-Artzi NISIカレン木陰のニューメキシコシリアルインタフェースジェフケースNOC Toolsボブを接待します; グループCHロキタンスキーPerformanceとCCアリソン・マンキンを発送するEnger OSPFマイクPetryオープンシステムルート設定マリアンエレップOSI相互運用性ロスCallon PDNが指します--ポイントIPドリュー・パーキンス、CO-IPクラウディオTopolcic telnetデーヴボーマンユーザドキュメントカレンRoubicekユーザサービスカレン第木陰
Routing
ルート設定
Routing is the algorithm by which a network directs a packet from its source to its destination. To appreciate the problem, watch a small child trying to find a table in a restaurant. From the adult point of view, the structure of the dining room is seen and an optimal route easily chosen. The child, however, is presented with a set of paths between tables where a good path, let alone the optimal one to the goal is not discernible.
ルート設定はネットワークがソースから目的地までパケットを指示するアルゴリズムです。 問題に感謝するには、小さい子供がレストランでテーブルを見つけようとしているのを見てください。 ダイニングルームの構造は、大人の観点から、見られて容易に選ばれた最適のルートです。 しかしながら、良い経路でありまして、目標への最適のものが認識できないテーブルの間の1セットの経路を子供に与えます。
A little more background might be appropriate. IP gateways (more correctly routers) are boxes which have connections to multiple networks and pass traffic between these nets. They decide how the packet is to be sent based on the information in the IP header of the packet and the state of the network. Each interface on a router has an unique address appropriate to the network to which it is connected. The information in the IP header which is used is primarily the destination address. Other information (e.g., type of service) is largely ignored at this time. The state of the network is determined by the routers passing information among themselves. The distribution of the database (what each node knows), the form of the updates, and metrics used to measure the value of a connection, are the parameters which determine the characteristics of a routing protocol.
バックグラウンドはもう少し適切であるかもしれません。 IPゲートウェイ、(より正しさ、ルータ) 複数のネットワークには接続があって、間にトラフィックを通過する箱はこれらのネットですか? 彼らはパケットがパケットのIPヘッダーとネットワークの事情の情報に基づいて送られることになっている方法を決めます。 ルータの各インタフェースで、ユニークなアドレスはそれが関連しているネットワークに適切になります。 使用されたIPヘッダーの情報は主として送付先アドレスです。 他の情報(例えば、サービスのタイプ)はこのとき、主に無視されます。 ネットワークの事情は情報を自分たちに渡すルータで決定します。 データベース(各ノードが知っていること)の分配、アップデート、および接続の値を測定するのに使用される測定基準のフォームはルーティング・プロトコルの特性を決定するパラメタです。
Under some algorithms, each node in the network has complete
いくつかのアルゴリズム、ネットワークにおけるノードが完全にするそれぞれ下で
Krol [Page 10] RFC 1118 The Hitchhikers Guide to the Internet September 1989
ヒッチハイカーが1989年9月にインターネットに誘導するクロール[10ページ]RFC1118
knowledge of the state of the network (the adult algorithm). This implies the nodes must have larger amounts of local storage and enough CPU to search the large tables in a short enough time (remember, this must be done for each packet). Also, routing updates usually contain only changes to the existing information (or you spend a large amount of the network capacity passing around megabyte routing updates). This type of algorithm has several problems. Since the only way the routing information can be passed around is across the network and the propagation time is non-trivial, the view of the network at each node is a correct historical view of the network at varying times in the past. (The adult algorithm, but rather than looking directly at the dining area, looking at a photograph of the dining room. One is likely to pick the optimal route and find a bus-cart has moved in to block the path after the photo was taken). These inconsistencies can cause circular routes (called routing loops) where once a packet enters it is routed in a closed path until its time to live (TTL) field expires and it is discarded.
ネットワーク(アダルトアルゴリズム)の事情に関する知識。 これは、ノードには多く以上の量の地方のストレージと大きいテーブルを捜すことができるくらいのCPUが十分短い間に後になければならないのを(各パケットのためにこれをしなければならなかったのを覚えていてください)含意します。 また、通常、ルーティングアップデートは既存情報への変化だけを含んでいます(あなたはネットワーク容量の多量をルーティングがアップデートするメガバイトを回すのに費やします)。 このタイプのアルゴリズムには、いくつかの問題があります。ルーティング情報を回すことができる唯一の方法がネットワークのむこうにあって、伝播時間が重要であるので、各ノードのネットワークの視点は過去に回を変えるところのネットワークの正しい歴史観です。 (アダルトアルゴリズム、ダイニングルームの写真を見て、直接食事領域を見るよりむしろ。 1つは、最適のルートを選んで、フォトを取った後にバスカートに経路を妨げるために入って来たのがわかりそうです。). これらの矛盾はパケットにいったん入るとそれが閉路で生きる時間(TTL)まで発送される分野が吐き出す円形のルート(ルーティング輪と呼ばれる)を引き起こす場合があります、そして、それは捨てられます。
Other algorithms may know about only a subset of the network. To prevent loops in these protocols, they are usually used in a hierarchical network. They know completely about their own area, but to leave that area they go to one particular place (the default gateway). Typically these are used in smaller networks (campus or regional).
他のアルゴリズムはネットワークの部分集合だけに関して知るかもしれません。 これらのプロトコルで輪を防ぐために、通常、それらは階層的なネットワークに使用されます。 完全なそれら自身の領域に関して知っていますが、それを領域に発つために、彼らは1つの特定の場所(デフォルトゲートウェイ)まで行きます。 通常これらは、より小さいネットワークに(キャンパスか地方)で使用されます。
Routing protocols in current use:
現在の使用でのルーティング・プロトコル:
Static (no protocol-table/default routing)
静電気(プロトコルテーブル/デフォルトが全く掘られないで)
Don't laugh. It is probably the most reliable, easiest to
implement, and least likely to get one into trouble for a small
network or a leaf on the Internet. This is, also, the only method
available on some CPU-operating system combinations. If a host is
connected to an Ethernet which has only one gateway off of it, one
should make that the default gateway for the host and do no other
routing. (Of course, that gateway may pass the reachability
information somehow on the other side of itself.)
笑わないでください。 それは、たぶん最も信頼できる、最も実装しやすくて、小さいネットワークかインターネットの葉のために1つに最も迷惑をかけそうにはありません。 また、これはいくつかのCPUオペレーティングシステム組み合わせのときに利用可能な唯一のメソッドです。 ホストがそれから1門しか持っていないイーサネットに接続されるなら、ホストのためにそれをデフォルトゲートウェイにして、どんな他のものにもルーティングするべきではありません。 (もちろん、そのゲートウェイはそれ自体の反対側でどうにか可到達性情報を通過するかもしれません。)
One word of warning, it is only with extreme caution that one
should use static routes in the middle of a network which is also
using dynamic routing. The routers passing dynamic information
are sometimes confused by conflicting dynamic and static routes.
If your host is on an ethernet with multiple routers to other
networks on it and the routers are doing dynamic routing among
themselves, it is usually better to take part in the dynamic
routing than to use static routes.
1つの戒めの言葉、単に極端な警告で、また、ダイナミックルーティングを使用しているネットワークの中央でスタティックルートを使用するべきです。 動的情報を通過するルータは闘争している動力とスタティックルートで時々混乱します。 それの他のネットワークにはあなたのホストが複数のルータと共にイーサネットにいて、ルータが自分たちの中でダイナミックルーティングをしているなら、通常、ダイナミックルーティングに参加するのはスタティックルートを使用するより良いです。
Krol [Page 11] RFC 1118 The Hitchhikers Guide to the Internet September 1989
ヒッチハイカーが1989年9月にインターネットに誘導するクロール[11ページ]RFC1118
RIP
裂け目
RIP is a routing protocol based on XNS (Xerox Network System)
adapted for IP networks. It is used by many routers (Proteon,
cisco, UB...) and many BSD Unix systems. BSD systems typically
run a program called "routed" to exchange information with other
systems running RIP. RIP works best for nets of small diameter
(few hops) where the links are of equal speed. The reason for
this is that the metric used to determine which path is best is
the hop-count. A hop is a traversal across a gateway. So, all
machines on the same Ethernet are zero hops away. If a router
connects connects two networks directly, a machine on the other
side of the router is one hop away. As the routing information is
passed through a gateway, the gateway adds one to the hop counts
to keep them consistent across the network. The diameter of a
network is defined as the largest hop-count possible within a
network. Unfortunately, a hop count of 16 is defined as infinity
in RIP meaning the link is down. Therefore, RIP will not allow
hosts separated by more than 15 gateways in the RIP space to
communicate.
RIPはIPネットワークのために適合させられたXNS(ゼロックスNetwork System)に基づくルーティング・プロトコルです。 それは多くのルータ(Proteon、コクチマス、UB…)と多くのBSD Unixシステムによって使用されます。BSDシステムは他のシステムがRIPを実行している状態で情報交換するために「発送されている」と呼ばれるプログラムを通常動かします。 RIPは小さい直径(わずかなホップ)のネットにリンクが等しい速度のものであるところにうまくいきます。 この理由はメートル法が、以前はよくどの経路が最も良いかが、ホップカウントであることを決定していたということです。 ホップはゲートウェイの向こう側の縦断です。 それで、同じイーサネットのすべてのマシンは遠くでホップではありません。 ルータが接続するaが直接2つのネットワークを接続するなら、ルータの反対側の上のマシンは遠くでワンバウンドです。 ルーティング情報がゲートウェイを通り抜けるとき、ゲートウェイは、ネットワークの向こう側に一貫しているようにそれらを保つためにホップカウントに1つを加えます。 ネットワークの直径はネットワークの中で可能な最も大きいホップカウントと定義されます。 残念ながら、16のホップカウントはリンクが下がっていることを意味するRIPで無限と定義されます。 したがって、RIPはRIPスペースの15門以上によって切り離されたホストを交信させないでしょう。
The other problem with hop-count metrics is that if links have
different speeds, that difference is not reflected in the hop-
count. So a one hop satellite link (with a .5 sec delay) at 56kb
would be used instead of a two hop T1 connection. Congestion can
be viewed as a decrease in the efficacy of a link. So, as a link
gets more congested, RIP will still know it is the best hop-count
route and congest it even more by throwing more packets on the
queue for that link.
ホップカウント測定基準に関するもう片方の問題はリンクに異なった速度があるなら、その違いがホップカウントに反映されないということです。 それで、56kbのワンバウンドの衛星中継(.5秒の遅れがある)は2ホップT1接続の代わりに使用されるでしょう。 リンクの効力の減少として混雑を見なすことができます。 それで、リンクがさらに充血するのに従って、RIPは、それが最も良いホップカウントルートであることをまだ知っていて、さらにそのリンクのための待ち行列により多くのパケットを投げさえすることによって、それを充血させるでしょう。
RIP was originally not well documented in the community and people
read BSD code to find out how RIP really worked. Finally, it was
documented in RFC-1058.
RIPは元々共同体によく記録されませんでした、そして、人々はRIPが本当にどのように働いていたかを見つけるためにコードをBSDに読み込みます。 最終的に、それはRFC-1058に記録されました。
Routed
掘ります。
The routed program, which does RIP for 4.2BSD systems, has many
options. One of the most frequently used is: "routed -q" (quiet
mode) which means listen to RIP information, but never broadcast
it. This would be used by a machine on a network with multiple
RIP speaking gateways. It allows the host to determine which
gateway is best (hopwise) to use to reach a distant network. (Of
course, you might want to have a default gateway to prevent having
to pass all the addresses known to the Internet around with RIP.)
発送されたプログラム(4.2BSDシステムのためにRIPをする)には、多くのオプションがあります。 頻繁に使用される大部分の1つは以下の通りです。 RIP情報を聞きますが、それを決して放送しないことを意味する「発送された-q。」(静かなモード) これはゲートウェイを話す複数のRIPと共にネットワークでマシンによって使用されるでしょう。 それで、ホストは、遠方のネットワークに達するようにどのゲートウェイが使用に最も良いかを(hopwiseします)決心できます。 (もちろん、あなたはRIPと共に周囲でインターネットに知られているすべてのアドレスを通過しなければならないのを防ぐためにデフォルトゲートウェイが欲しいかもしれません。)
There are two ways to insert static routes into routed; the
/etc/gateways file, and the "route add" command. Static routes
are useful if you know how to reach a distant network, but you are
スタティックルートを発送されるのに挿入する2つの方法があります。 /etc/gatewaysファイル、および「ルートは加える」というコマンド。 あなたが遠方のネットワークに達する方法を知っているなら、スタティックルートは役に立ちますが、あなたは役に立ちます。
Krol [Page 12] RFC 1118 The Hitchhikers Guide to the Internet September 1989
ヒッチハイカーが1989年9月にインターネットに誘導するクロール[12ページ]RFC1118
not receiving that route using RIP. For the most part the "route
add" command is preferable to use. The reason for this is that
the command adds the route to that machine's routing table but
does not export it through RIP. The /etc/gateways file takes
precedence over any routing information received through a RIP
update. It is also broadcast as fact in RIP updates produced by
the host without question, so if a mistake is made in the
/etc/gateways file, that mistake will soon permeate the RIP space
and may bring the network to its knees.
RIPを使用することでそのルートを受けません。 だいたい「ルートは加える」というコマンドが、使用するために望ましいです。 この理由はコマンドがそのマシンの経路指定テーブルにルートを加えますが、RIPを通してそれをエクスポートしないということです。 /etc/gatewaysファイルはRIPアップデートで受け取られたどんなルーティング情報の上でも優先します。 また、RIPアップデートにおける事実が確かにホストに作り出されたのでそれが放送されるので、/etc/gatewaysファイルで誤りをするなら、その誤りは、すぐ、RIPスペースを透過して、ネットワークを屈従させるかもしれません。
One of the problems with routed is that you have very little
control over what gets broadcast and what doesn't. Many times in
larger networks where various parts of the network are under
different administrative controls, you would like to pass on
through RIP only nets which you receive from RIP and you know are
reasonable. This prevents people from adding IP addresses to the
network which may be illegal and you being responsible for passing
them on to the Internet. This type of reasonability checks are
not available with routed and leave it usable, but inadequate for
large networks.
発送されるのに関する問題の1つはあなたが何が放送されるか、そして、何が放送されないかの上にほとんどコントロールを持っていないということです。 ネットワークの様々な部分が異なった運営管理コントロールの下にあって、あなたがRIPを通してRIPから受けるネットだけを伝えたがっていて、あなたが知っているより大きいネットワークにおける何回も妥当です。 これによって、人々はインターネットにそれらを向かわせるのに責任があるので、不法であるかもしれないネットワークとあなたにIPアドレスを追加できません。 このタイプの正当性チェックは、発送されることで利用可能でなく、それを使用可能ですが、大きいネットワークに不十分な状態でおきます。
Hello (RFC-891)
こんにちは(RFC-891)
Hello is a routing protocol which was designed and implemented in
a experimental software router called a "Fuzzball" which runs on a
PDP-11. It does not have wide usage, but is the routing protocol
formerly used on the initial NSFNET backbone. The data
transferred between nodes is similar to RIP (a list of networks
and their metrics). The metric, however, is milliseconds of
delay. This allows Hello to be used over nets of various link
speeds and performs better in congestive situations.
こんにちは、PDP-11の上で作業する"Fuzzball"と呼ばれる実験的なソフトウェアルータで設計されて、実装されたルーティング・プロトコルはそうですか? それは、広い用法を持っていませんが、以前初期のNSFNETバックボーンで使用されたルーティング・プロトコルです。 ノードの間に移されたデータはRIP(ネットワークとそれらの測定基準のリスト)と同様です。 しかしながら、メートル法はミリセカンドの遅れです。 これは、Helloが様々なリンク速度の正価の上で使用されるのを許容して、充血性の状況でよく振る舞います。
One of the most interesting side effects of Hello based networks
is their great timekeeping ability. If you consider the problem
of measuring delay on a link for the metric, you find that it is
not an easy thing to do. You cannot measure round trip time since
the return link may be more congested, of a different speed, or
even not there. It is not really feasible for each node on the
network to have a builtin WWV (nationwide radio time standard)
receiver. So, you must design an algorithm to pass around time
between nodes over the network links where the delay in
transmission can only be approximated. Hello routers do this and
in a nationwide network maintain synchronized time within
milliseconds. (See also the Network Time Protocol, RFC-1059.)
Helloのベースのネットワークの最もおもしろい副作用の1つは彼らのかなりの時間保持能力です。 メートル法のためにリンクの上に遅れを測定するという問題を考えるなら、あなたは、それがことでないことがわかりますしやすい。 あなたはリターンリンクが異なった速度についてさらに充血するかもしれなくて以来の旅行時間の周りかそこでないところでさえ測定できません。 ネットワークの各ノードには作り付けのWWV(全国的なラジオ時間規格)受信機があるのは、本当に可能ではありません。あなたは、およそ時間トランスミッションの遅れに近似できるだけであるネットワークリンクの上のノードの間を通るようにアルゴリズムを設計しなければなりません。 こんにちは、ルータは、これをして、全国中継でそうします。ミリセカンドの中で連動している時間を維持してください。 (RFC-1059、また、Network Timeプロトコルを見てください。)
Krol [Page 13] RFC 1118 The Hitchhikers Guide to the Internet September 1989
ヒッチハイカーが1989年9月にインターネットに誘導するクロール[13ページ]RFC1118
Gateway Gateway Protocol (GGP RFC-823)
ゲートウェイゲートウェイプロトコル(GGP RFC-823)
The core gateways originally used GGP to exchange information
among themselves. This is a "distance-vector" algorithm. The new
core gateways use a "link-state" algorithm.
コアゲートウェイは、元々、自分たちの中で情報交換するのにGGPを使用しました。 これは「距離ベクトル」アルゴリズムです。 新しいコアゲートウェイは「リンク状態」アルゴリズムを使用します。
NSFNET SPF (RFC-1074)
NSFNET SPF(RFC-1074)
The current NSFNET Backbone routers use a version of the ANSI IS-
IS and ISO ES-IS routing protocol. This is a "shortest path
first" (SPF) algorithm which is in the class of "link-state"
algorithms.
現在のNSFNET BackboneルータがANSI ISのバージョンを使用する、ISO ES存在、ルーティング・プロトコル。 これがaである、「最短パス、」 最初に、「リンク状態」アルゴリズムのクラスにはある(SPF)アルゴリズム。
Exterior Gateway Protocol (EGP RFC-904)
外のゲートウェイプロトコル(EGP RFC-904)
EGP is not strictly a routing protocol, it is a reachability
protocol. It tells what nets can be reached through what gateway,
but not how good the connection is. It is the standard by which
gateways exchange network reachability information with the core
gateways. It is generally used between autonomous systems. There
is a metric passed around by EGP, but its usage is not
standardized formally. The metric's value ranges from 0 to 255
with smaller values considered "better". Some implementations
consider the value 255 to mean unreachable. Many routers talk EGP
so they can be used to interface to routers of different
manufacture or operated by different administrations. For
example, when a router of the NSFNET Backbone exchanges routing or
reachability information with a gateway of a regional network EGP
is used.
EGPによるルーティング・プロトコルであり厳密に、それが可到達性プロトコルであるということではありません。 それは、どんなネットにどんなゲートウェイを通して達することができるか、しかし、接続がどれくらい良くないかを言います。 それはゲートウェイがネットワーク可到達性情報をコアゲートウェイと交換する規格です。 一般に、それは自律システムの間で使用されます。EGPによって回されて、そこでは、aがメートル法ですが、用法は正式に標準化されません。 メートル法による、より小さい値が「より良い」と考えられている0〜255までの値の範囲です。 いくつかの実装が、値255が手が届かないことを意味すると考えます。 それらを異なった製造のルータに連結するのに使用するか、または異なった政権が運用できるように、多くのルータがEGPについて話します。 例えば、NSFNET Backboneのルータがいつルーティングを交換するか、そして、地方のネットワークEGPのゲートウェイがある可到達性情報が使用されています。
Gated
外出を禁止されます。
So we have regional and campus networks talking RIP among
themselves and the DDN and NSFNET speaking EGP. How do they
interoperate? In the beginning, there was static routing. The
problem with doing static routing in the middle of the network is
that it is broadcast to the Internet whether it is usable or not.
Therefore, if a net becomes unreachable and you try to get there,
dynamic routing will immediately issue a net unreachable to you.
Under static routing the routers would think the net could be
reached and would continue trying until the application gave up
(in 2 or more minutes). Mark Fedor, then of Cornell, attempted to
solve these problems with a replacement for routed called gated.
それで、私たちは自分たちの中でRIPについて話す地方とキャンパスネットワーク、DDN、およびNSFNETにEGPを話させます。 彼らはどのように共同利用しますか? 初めに、スタティックルーティングがありました。 ネットワークの中央でスタティックルーティングをすることに関する問題は使用可能であるか否かに関係なく、それがインターネットに放送されるということです。 したがって、ネットが手が届かなくなって、あなたがそこに到着しようとすると、ダイナミックルーティングはすぐに、あなたにとって、手の届かないネットを発行するでしょう。 スタティックルーティングの下では、ルータは、ネットに達することができたと思って、アプリケーションがあきらめるまで、試み続けているでしょう(2分以上後に)。 外出を禁止されると呼ばれて、解決するヒョードルが交換に関するこれらの問題をそして、コーネルに試みたマークは掘られました。
Gated talks RIP to RIP speaking hosts, EGP to EGP speakers, and
Hello to Hello'ers. These speakers frequently all live on one
Ethernet, but luckily (or unluckily) cannot understand each others
ruminations. In addition, under configuration file control it can
会談のホスト(EGPスピーカーへのEGP)を話すRIPへのRIPとHello'ersへのHelloに外出を禁止しました。 これらのスピーカーは、頻繁に1つのイーサネットですべて、生活しますが、他のもののためにそれぞれ反芻を運よく理解できません(不運にも)。 さらに、構成ファイルコントロールの下では、それはそうすることができます。
Krol [Page 14] RFC 1118 The Hitchhikers Guide to the Internet September 1989
ヒッチハイカーが1989年9月にインターネットに誘導するクロール[14ページ]RFC1118
filter the conversion. For example, one can produce a
configuration saying announce RIP nets via Hello only if they are
specified in a list and are reachable by way of a RIP broadcast as
well. This means that if a rogue network appears in your local
site's RIP space, it won't be passed through to the Hello side of
the world. There are also configuration options to do static
routing and name trusted gateways.
変換をフィルターにかけてください。 例えば、1つはそれらがリストで指定されて、また、RIP放送を通して届く場合にだけHelloを通してRIPネットを発表するように言う構成を発生させることができます。 これは、違法のネットワークがあなたのローカル・サイトのRIPスペースに現れるなら、それが世界のHello端に通り抜けないことを意味します。 スタティックルーティングをして、信じられたゲートウェイを命名するために、設定オプションもあります。
This may sound like the greatest thing since sliced bread, but
there is a catch called metric conversion. You have RIP measuring
in hops, Hello measuring in milliseconds, and EGP using arbitrary
small numbers. The big questions is how many hops to a
millisecond, how many milliseconds in the EGP number 3.... Also,
remember that infinity (unreachability) is 16 to RIP, 30000 or so
to Hello, and 8 to the DDN with EGP. Getting all these metrics to
work well together is no small feat. If done incorrectly and you
translate an RIP of 16 into an EGP of 6, everyone in the ARPANET
will still think your gateway can reach the unreachable and will
send every packet in the world your way. Gated is available via
anonymous FTP from devvax.tn.cornell.edu in directory pub/gated.
最もすばらしいものが以来パンを切りましたが、メートル法の変換と呼ばれるキャッチがあるようにこれは聞こえるかもしれません。 あなたは、RIPにホップ、ミリセカンドで測定するHello、およびEGPで任意の少ない数を使用することで測定させます。 大きい質問はいくつが1ミリセカンド、EGP No.3における何人のミリセカンドまで跳ぶかということです… また、無限(「非-可到達性」)がRIPへの16と、Helloへのおよそ30000と、EGPとDDNへの8であることを覚えていてください。 これらのすべての測定基準を一緒にうまくいかせるのは、小さいフィーチャリングではありません。 そして、不当にする、あなたが16のRIPを6のEGPに翻訳して、アルパネットにおける皆は、それでも、あなたのゲートウェイが手の届かなさに達することができると考えて、世界のあらゆるパケットにあなたのやり方を送るでしょう。 ゲート、devvax.tn.cornell.eduからの公開FTPで、ディレクトリパブ/外出を禁止されるところで利用可能です。
Names
名前
All routing across the network is done by means of the IP address associated with a packet. Since humans find it difficult to remember addresses like 128.174.5.50, a symbolic name register was set up at the NIC where people would say, "I would like my host to be named uiucuxc". Machines connected to the Internet across the nation would connect to the NIC in the middle of the night, check modification dates on the hosts file, and if modified, move it to their local machine. With the advent of workstations and micros, changes to the host file would have to be made nightly. It would also be very labor intensive and consume a lot of network bandwidth. RFC-1034 and a number of others describe Domain Name Service (DNS), a distributed data base system for mapping names into addresses.
パケットに関連しているIPアドレスによってネットワークの向こう側のすべてのルーティングをします。 以来人間が、それがアドレスを覚えているのが難しいのがわかる、128.174、.5、.50、英字名レジスタは人々が「私のホストをuiucuxcと命名されたいと思います」と言うNICにセットアップされました。 国の向こう側にインターネットに接続されたマシンは夜中にNICに接続するでしょう、そして、ホストに関する日付がファイルする変更をチェックしてください、そして、変更されるなら、それを地元のマシンに動かしてください。 ワークステーションとミクロの到来で、ホストファイルへの変更を連夜にしなければならないでしょう。 それは、また、労働非常に徹底的であり、多くのネットワーク回線容量を消費するでしょう。 RFC-1034と多くの他のものがDomain Name Service(DNS)(名前をアドレスに写像する分散形データベースシステム)について説明します。
We must look a little more closely into what's in a name. First, note that an address specifies a particular connection on a specific network. If the machine moves, the address changes. Second, a machine can have one or more names and one or more network addresses (connections) to different networks. Names point to a something which does useful work (i.e., the machine) and IP addresses point to an interface on that provider. A name is a purely symbolic representation of a list of addresses on the network. If a machine moves to a different network, the addresses will change but the name could remain the same.
私たちはもう少し密接に名前にはあるものを調べなければなりません。 まず最初に、アドレスが特定のネットワークで特定の接続を指定することに注意してください。 マシンが移行するなら、アドレスは変化します。 2番目に、マシンは1つ以上の名前と1つ以上のネットワーク・アドレス(接続)を異なったネットワークに持つことができます。 そのプロバイダーで有益な仕事する何か(すなわち、マシン)とIPアドレスへのポイントをインタフェースへのポイントと命名します。 名前はネットワークにおける住所録の純粋にシンボリックな表現です。 マシンが異なったネットワークに移行すると、アドレスは変化するでしょうが、名前は同じままで残ることができました。
Domain names are tree structured names with the root of the tree at
ドメイン名は木の根の木の構造化された名です。
Krol [Page 15] RFC 1118 The Hitchhikers Guide to the Internet September 1989
ヒッチハイカーが1989年9月にインターネットに誘導するクロール[15ページ]RFC1118
the right. For example:
権利。 例えば:
uxc.cso.uiuc.edu
uxc.cso.uiuc.edu
is a machine called "uxc" (purely arbitrary), within the subdomains of the U of I, and "uiuc" (the University of Illinois at Urbana), registered with "edu" (the set of educational institutions).
呼ばれるマシンが"uxc"であるという(純粋に任意)のIのUに関するサブドメイン以内に「uiuc」(アーバナのイリノイ大学)登録された"edu"(学園のセット)。
A simplified model of how a name is resolved is that on the user's machine there is a resolver. The resolver knows how to contact across the network a root name server. Root servers are the base of the tree structured data retrieval system. They know who is responsible for handling first level domains (e.g., 'edu'). What root servers to use is an installation parameter. From the root server the resolver finds out who provides 'edu' service. It contacts the 'edu' name server which supplies it with a list of addresses of servers for the subdomains (like 'uiuc'). This action is repeated with the sub-domain servers until the final subdomain returns a list of addresses of interfaces on the host in question. The user's machine then has its choice of which of these addresses to use for communication.
名前がどう決議されているかに関する簡易型のモデルはユーザのマシンの上に、レゾルバがあるということです。レゾルバはネットワークの向こう側に根のネームサーバに連絡する方法を知っています。ルートサーバーは木の構造化されたデータ情報検索システムのベースです。 彼らは、だれが最初の平らなドメイン(例えば、'edu')を扱うのに責任があるかを知っています。 どんなルートサーバーを使用したらよいかは、インストールパラメタです。 ルートサーバーから、レゾルバは、だれが'edu'サービスを提供するかを見つけます。 それはサブドメイン('uiuc'のような)のためにサーバに関する住所録をそれに供給する'edu'ネームサーバに連絡します。 最終的なサブドメインが問題のホストの上でインタフェースに関する住所録を返すまで、この動作はサブドメインサーバで繰り返されます。 そして、ユーザのマシンには、選択がコミュニケーションにこれらのアドレスのどれを使用するかをあります。
A group may apply for its own domain name (like 'uiuc' above). This is done in a manner similar to the IP address allocation. The only requirements are that the requestor have two machines reachable from the Internet, which will act as name servers for that domain. Those servers could also act as servers for subdomains or other servers could be designated as such. Note that the servers need not be located in any particular place, as long as they are reachable for name resolution. (U of I could ask Michigan State to act on its behalf and that would be fine.) The biggest problem is that someone must do maintenance on the database. If the machine is not convenient, that might not be done in a timely fashion. The other thing to note is that once the domain is allocated to an administrative entity, that entity can freely allocate subdomains using what ever manner it sees fit.
グループはそれ自身のドメイン名(上の'uiuc'のような)に申し込むかもしれません。 IPアドレス配分と同様の方法でこれをします。 唯一の要件は要請者が2台のマシンをそのドメインへのネームサーバとして機能するインターネットから届くようにするということです。 また、それらのサーバはそういうものとしてサブドメインのためのサーバか他のサーバを指定できたように行動できました。 サーバがどんな特定の場所にも位置する必要はないことに注意してください、名前解決において、それらが届いている限り。 (IのUは、利益に影響するようにミシガン州に頼むことができて、それはすばらしいでしょう。) 最も大きい問題はだれかがデータベースでメインテナンスをしなければならないということです。 マシンが都合がよくないなら、直ちにそれをしないかもしれません。 注意するもう片方のことはいったんドメインを割り当てると管理実体、缶が自由にいったい何を使用するサブドメインを割り当てるその実体に、それが見る方法が合ったということです。
The Berkeley Internet Name Domain (BIND) Server implements the Internet name server for UNIX systems. The name server is a distributed data base system that allows clients to name resources and to share that information with other network hosts. BIND is integrated with 4.3BSD and is used to lookup and store host names, addresses, mail agents, host information, and more. It replaces the /etc/hosts file or host name lookup. BIND is still an evolving program. To keep up with reports on operational problems, future design decisions, etc., join the BIND mailing list by sending a request to Bind-Request@UCBARPA.BERKELEY.EDU. BIND can also be obtained via anonymous FTP from ucbarpa.berkeley.edu.
バークレーインターネットName Domain(BIND)サーバはUNIXシステムのためにインターネットネームサーバを実装します。ネームサーバはクライアントがリソースを任命して、他のネットワークホストとその情報を共有する分散形データベースシステムです。 BINDは4.3BSDについて統合していて、ルックアップ、店ホスト名、アドレス、メールエージェント、ホスト情報、およびその他に使用されます。 それは/etc/hostsファイルかホスト名ルックアップを置き換えます。 BINDは発展プログラムです。 運転上の問題、今後のデザイン決定などに関するレポートについて行くには、要求を Bind-Request@UCBARPA.BERKELEY.EDU に送ることによって、BINDメーリングリストを接合してください。 また、ucbarpa.berkeley.eduからの公開FTPでBINDを入手できます。
Krol [Page 16] RFC 1118 The Hitchhikers Guide to the Internet September 1989
ヒッチハイカーが1989年9月にインターネットに誘導するクロール[16ページ]RFC1118
There are several advantages in using BIND. One of the most important is that it frees a host from relying on /etc/hosts being up to date and complete. Within the .uiuc.edu domain, only a few hosts are included in the host table distributed by SRI. The remainder are listed locally within the BIND tables on uxc.cso.uiuc.edu (the server machine for most of the .uiuc.edu domain). All are equally reachable from any other Internet host running BIND, or any DNS resolver.
There are several advantages in using BIND. One of the most important is that it frees a host from relying on /etc/hosts being up to date and complete. Within the .uiuc.edu domain, only a few hosts are included in the host table distributed by SRI. The remainder are listed locally within the BIND tables on uxc.cso.uiuc.edu (the server machine for most of the .uiuc.edu domain). All are equally reachable from any other Internet host running BIND, or any DNS resolver.
BIND can also provide mail forwarding information for interior hosts not directly reachable from the Internet. These hosts an either be on non-advertised networks, or not connected to an IP network at all, as in the case of UUCP-reachable hosts (see RFC-974). More information on BIND is available in the "Name Server Operations Guide for BIND" in UNIX System Manager's Manual, 4.3BSD release.
BIND can also provide mail forwarding information for interior hosts not directly reachable from the Internet. These hosts an either be on non-advertised networks, or not connected to an IP network at all, as in the case of UUCP-reachable hosts (see RFC-974). More information on BIND is available in the "Name Server Operations Guide for BIND" in UNIX System Manager's Manual, 4.3BSD release.
There are a few special domains on the network, like NIC.DDN.MIL. The hosts database at the NIC. There are others of the form NNSC.NSF.NET. These special domains are used sparingly, and require ample justification. They refer to servers under the administrative control of the network rather than any single organization. This allows for the actual server to be moved around the net while the user interface to that machine remains constant. That is, should BBN relinquish control of the NNSC, the new provider would be pointed to by that name.
There are a few special domains on the network, like NIC.DDN.MIL. The hosts database at the NIC. There are others of the form NNSC.NSF.NET. These special domains are used sparingly, and require ample justification. They refer to servers under the administrative control of the network rather than any single organization. This allows for the actual server to be moved around the net while the user interface to that machine remains constant. That is, should BBN relinquish control of the NNSC, the new provider would be pointed to by that name.
In actuality, the domain system is a much more general and complex system than has been described. Resolvers and some servers cache information to allow steps in the resolution to be skipped. Information provided by the servers can be arbitrary, not merely IP addresses. This allows the system to be used both by non-IP networks and for mail, where it may be necessary to give information on intermediate mail bridges.
In actuality, the domain system is a much more general and complex system than has been described. Resolvers and some servers cache information to allow steps in the resolution to be skipped. Information provided by the servers can be arbitrary, not merely IP addresses. This allows the system to be used both by non-IP networks and for mail, where it may be necessary to give information on intermediate mail bridges.
What's wrong with Berkeley Unix
What's wrong with Berkeley Unix
University of California at Berkeley has been funded by DARPA to modify the Unix system in a number of ways. Included in these modifications is support for the Internet protocols. In earlier versions (e.g., BSD 4.2) there was good support for the basic Internet protocols (TCP, IP, SMTP, ARP) which allowed it to perform nicely on IP Ethernets and smaller Internets. There were deficiencies, however, when it was connected to complicated networks. Most of these problems have been resolved under the newest release (BSD 4.3). Since it is the springboard from which many vendors have launched Unix implementations (either by porting the existing code or by using it as a model), many implementations (e.g., Ultrix) are still based on BSD 4.2. Therefore, many implementations still exist with the BSD 4.2 problems. As time goes on, when BSD 4.3 trickles
University of California at Berkeley has been funded by DARPA to modify the Unix system in a number of ways. Included in these modifications is support for the Internet protocols. In earlier versions (e.g., BSD 4.2) there was good support for the basic Internet protocols (TCP, IP, SMTP, ARP) which allowed it to perform nicely on IP Ethernets and smaller Internets. There were deficiencies, however, when it was connected to complicated networks. Most of these problems have been resolved under the newest release (BSD 4.3). Since it is the springboard from which many vendors have launched Unix implementations (either by porting the existing code or by using it as a model), many implementations (e.g., Ultrix) are still based on BSD 4.2. Therefore, many implementations still exist with the BSD 4.2 problems. As time goes on, when BSD 4.3 trickles
Krol [Page 17] RFC 1118 The Hitchhikers Guide to the Internet September 1989
Krol [Page 17] RFC 1118 The Hitchhikers Guide to the Internet September 1989
through vendors as new release, many of the problems will be resolved. Following is a list of some problem scenarios and their handling under each of these releases.
through vendors as new release, many of the problems will be resolved. Following is a list of some problem scenarios and their handling under each of these releases.
ICMP redirects
ICMP redirects
Under the Internet model, all a system needs to know to get
anywhere in the Internet is its own address, the address of where
it wants to go, and how to reach a gateway which knows about the
Internet. It doesn't have to be the best gateway. If the system
is on a network with multiple gateways, and a host sends a packet
for delivery to a gateway which feels another directly connected
gateway is more appropriate, the gateway sends the sender a
message. This message is an ICMP redirect, which politely says,
"I'll deliver this message for you, but you really ought to use
that gateway over there to reach this host". BSD 4.2 ignores
these messages. This creates more stress on the gateways and the
local network, since for every packet sent, the gateway sends a
packet to the originator. BSD 4.3 uses the redirect to update its
routing tables, will use the route until it times out, then revert
to the use of the route it thinks is should use. The whole
process then repeats, but it is far better than one per packet.
Under the Internet model, all a system needs to know to get anywhere in the Internet is its own address, the address of where it wants to go, and how to reach a gateway which knows about the Internet. It doesn't have to be the best gateway. If the system is on a network with multiple gateways, and a host sends a packet for delivery to a gateway which feels another directly connected gateway is more appropriate, the gateway sends the sender a message. This message is an ICMP redirect, which politely says, "I'll deliver this message for you, but you really ought to use that gateway over there to reach this host". BSD 4.2 ignores these messages. This creates more stress on the gateways and the local network, since for every packet sent, the gateway sends a packet to the originator. BSD 4.3 uses the redirect to update its routing tables, will use the route until it times out, then revert to the use of the route it thinks is should use. The whole process then repeats, but it is far better than one per packet.
Trailers
Trailers
An application (like FTP) sends a string of octets to TCP which
breaks it into chunks, and adds a TCP header. TCP then sends
blocks of data to IP which adds its own headers and ships the
packets over the network. All this prepending of the data with
headers causes memory moves in both the sending and the receiving
machines. Someone got the bright idea that if packets were long
and they stuck the headers on the end (they became trailers), the
receiving machine could put the packet on the beginning of a page
boundary and if the trailer was OK merely delete it and transfer
control of the page with no memory moves involved. The problem is
that trailers were never standardized and most gateways don't know
to look for the routing information at the end of the block. When
trailers are used, the machine typically works fine on the local
network (no gateways involved) and for short blocks through
gateways (on which trailers aren't used). So TELNET and FTP's of
very short files work just fine and FTP's of long files seem to
hang. On BSD 4.2 trailers are a boot option and one should make
sure they are off when using the Internet. BSD 4.3 negotiates
trailers, so it uses them on its local net and doesn't use them
when going across the network.
An application (like FTP) sends a string of octets to TCP which breaks it into chunks, and adds a TCP header. TCP then sends blocks of data to IP which adds its own headers and ships the packets over the network. All this prepending of the data with headers causes memory moves in both the sending and the receiving machines. Someone got the bright idea that if packets were long and they stuck the headers on the end (they became trailers), the receiving machine could put the packet on the beginning of a page boundary and if the trailer was OK merely delete it and transfer control of the page with no memory moves involved. The problem is that trailers were never standardized and most gateways don't know to look for the routing information at the end of the block. When trailers are used, the machine typically works fine on the local network (no gateways involved) and for short blocks through gateways (on which trailers aren't used). So TELNET and FTP's of very short files work just fine and FTP's of long files seem to hang. On BSD 4.2 trailers are a boot option and one should make sure they are off when using the Internet. BSD 4.3 negotiates trailers, so it uses them on its local net and doesn't use them when going across the network.
Krol [Page 18] RFC 1118 The Hitchhikers Guide to the Internet September 1989
Krol [Page 18] RFC 1118 The Hitchhikers Guide to the Internet September 1989
Retransmissions
Retransmissions
TCP fires off blocks to its partner at the far end of the
connection. If it doesn't receive an acknowledgement in a
reasonable amount of time it retransmits the blocks. The
determination of what is reasonable is done by TCP's
retransmission algorithm.
TCP fires off blocks to its partner at the far end of the connection. If it doesn't receive an acknowledgement in a reasonable amount of time it retransmits the blocks. The determination of what is reasonable is done by TCP's retransmission algorithm.
There is no correct algorithm but some are better than others,
where worse is measured by the number of retransmissions done
unnecessarily. BSD 4.2 had a retransmission algorithm which
retransmitted quickly and often. This is exactly what you would
want if you had a bunch of machines on an Ethernet (a low delay
network of large bandwidth). If you have a network of relatively
longer delay and scarce bandwidth (e.g., 56kb lines), it tends to
retransmit too aggressively. Therefore, it makes the networks and
gateways pass more traffic than is really necessary for a given
conversation. Retransmission algorithms do adapt to the delay of
the network after a few packets, but 4.2's adapts slowly in delay
situations. BSD 4.3 does a lot better and tries to do the best
for both worlds. It fires off a few retransmissions really
quickly assuming it is on a low delay network, and then backs off
very quickly. It also allows the delay to be about 4 minutes
before it gives up and declares the connection broken.
There is no correct algorithm but some are better than others, where worse is measured by the number of retransmissions done unnecessarily. BSD 4.2 had a retransmission algorithm which retransmitted quickly and often. This is exactly what you would want if you had a bunch of machines on an Ethernet (a low delay network of large bandwidth). If you have a network of relatively longer delay and scarce bandwidth (e.g., 56kb lines), it tends to retransmit too aggressively. Therefore, it makes the networks and gateways pass more traffic than is really necessary for a given conversation. Retransmission algorithms do adapt to the delay of the network after a few packets, but 4.2's adapts slowly in delay situations. BSD 4.3 does a lot better and tries to do the best for both worlds. It fires off a few retransmissions really quickly assuming it is on a low delay network, and then backs off very quickly. It also allows the delay to be about 4 minutes before it gives up and declares the connection broken.
Even better than the original 4.3 code is a version of TCP with a
retransmission algorithm developed by Van Jacobson of LBL. He did
a lot of research into how the algorithm works on real networks
and modified it to get both better throughput and be friendlier to
the network. This code has been integrated into the later
releases of BSD 4.3 and can be fetched anonymously from
ucbarpa.berkeley.edu in directory 4.3.
Even better than the original 4.3 code is a version of TCP with a retransmission algorithm developed by Van Jacobson of LBL. He did a lot of research into how the algorithm works on real networks and modified it to get both better throughput and be friendlier to the network. This code has been integrated into the later releases of BSD 4.3 and can be fetched anonymously from ucbarpa.berkeley.edu in directory 4.3.
Time to Live
Time to Live
The IP packet header contains a field called the time to live
(TTL) field. It is decremented each time the packet traverses a
gateway. TTL was designed to prevent packets caught in routing
loops from being passed forever with no hope of delivery. Since
the definition bears some likeness to the RIP hop count, some
misguided systems have set the TTL field to 15 because the
unreachable flag in RIP is 16. Obviously, no networks could have
more than 15 hops. The RIP space where hops are limited ends when
RIP is not used as a routing protocol any more (e.g., when NSFnet
starts transporting the packet). Therefore, it is quite easy for
a packet to require more than 15 hops. These machines will
exhibit the behavior of being able to reach some places but not
others even though the routing information appears correct.
The IP packet header contains a field called the time to live (TTL) field. It is decremented each time the packet traverses a gateway. TTL was designed to prevent packets caught in routing loops from being passed forever with no hope of delivery. Since the definition bears some likeness to the RIP hop count, some misguided systems have set the TTL field to 15 because the unreachable flag in RIP is 16. Obviously, no networks could have more than 15 hops. The RIP space where hops are limited ends when RIP is not used as a routing protocol any more (e.g., when NSFnet starts transporting the packet). Therefore, it is quite easy for a packet to require more than 15 hops. These machines will exhibit the behavior of being able to reach some places but not others even though the routing information appears correct.
Krol [Page 19] RFC 1118 The Hitchhikers Guide to the Internet September 1989
Krol [Page 19] RFC 1118 The Hitchhikers Guide to the Internet September 1989
Solving the problem typically requires kernel patches so it may be
difficult if source is not available.
Solving the problem typically requires kernel patches so it may be difficult if source is not available.
Appendix A - References to Remedial Information -----------------------------------------------
Appendix A - References to Remedial Information -----------------------------------------------
[1] Quarterman and Hoskins, "Notable Computer Networks",
Communications of the ACM, Vol. 29, No. 10, pp. 932-971, October
1986.
[1] Quarterman and Hoskins, "Notable Computer Networks", Communications of the ACM, Vol. 29, No. 10, pp. 932-971, October 1986.
[2] Tannenbaum, A., "Computer Networks", Prentice Hall, 1981.
[2] Tannenbaum, A., "Computer Networks", Prentice Hall, 1981.
[3] Hedrick, C., "Introduction to the Internet Protocols", Via
Anonymous FTP from topaz.rutgers.edu, directory pub/tcp-ip-docs,
file tcp-ip-intro.doc.
[3] Hedrick, C., "Introduction to the Internet Protocols", Via Anonymous FTP from topaz.rutgers.edu, directory pub/tcp-ip-docs, file tcp-ip-intro.doc.
[4] Comer, D., "Internetworking with TCP/IP: Principles, Protocols,
and Architecture", Copyright 1988, by Prentice-Hall, Inc.,
Englewood Cliffs, NJ, 07632 ISBN 0-13-470154-2.
[4] Comer, D., "Internetworking with TCP/IP: Principles, Protocols, and Architecture", Copyright 1988, by Prentice-Hall, Inc., Englewood Cliffs, NJ, 07632 ISBN 0-13-470154-2.
Appendix B - List of Major RFCs -------------------------------
Appendix B - List of Major RFCs -------------------------------
This list of key "Basic Beige" RFCs was compiled by J.K. Reynolds. This is the 30 August 1989 edition of the list.
This list of key "Basic Beige" RFCs was compiled by J.K. Reynolds. This is the 30 August 1989 edition of the list.
RFC-768 User Datagram Protocol (UDP)
RFC-791 Internet Protocol (IP)
RFC-792 Internet Control Message Protocol (ICMP)
RFC-793 Transmission Control Protocol (TCP)
RFC-821 Simple Mail Transfer Protocol (SMTP)
RFC-822 Standard for the Format of ARPA Internet Text Messages
RFC-826 Ethernet Address Resolution Protocol
RFC-854 Telnet Protocol
RFC-862 Echo Protocol
RFC-894 A Standard for the Transmission of IP
Datagrams over Ethernet Networks
RFC-904 Exterior Gateway Protocol
RFC-919 Broadcasting Internet Datagrams
RFC-922 Broadcasting Internet Datagrams in the Presence of Subnets
RFC-950 Internet Standard Subnetting Procedure
RFC-951 Bootstrap Protocol (BOOTP)
RFC-959 File Transfer Protocol (FTP)
RFC-966 Host Groups: A Multicast Extension to the Internet Protocol
RFC-974 Mail Routing and the Domain System
RFC-1000 The Request for Comments Reference Guide
RFC-1009 Requirements for Internet Gateways
RFC-1010 Assigned Numbers
RFC-768 User Datagram Protocol (UDP) RFC-791 Internet Protocol (IP) RFC-792 Internet Control Message Protocol (ICMP) RFC-793 Transmission Control Protocol (TCP) RFC-821 Simple Mail Transfer Protocol (SMTP) RFC-822 Standard for the Format of ARPA Internet Text Messages RFC-826 Ethernet Address Resolution Protocol RFC-854 Telnet Protocol RFC-862 Echo Protocol RFC-894 A Standard for the Transmission of IP Datagrams over Ethernet Networks RFC-904 Exterior Gateway Protocol RFC-919 Broadcasting Internet Datagrams RFC-922 Broadcasting Internet Datagrams in the Presence of Subnets RFC-950 Internet Standard Subnetting Procedure RFC-951 Bootstrap Protocol (BOOTP) RFC-959 File Transfer Protocol (FTP) RFC-966 Host Groups: A Multicast Extension to the Internet Protocol RFC-974 Mail Routing and the Domain System RFC-1000 The Request for Comments Reference Guide RFC-1009 Requirements for Internet Gateways RFC-1010 Assigned Numbers
Krol [Page 20] RFC 1118 The Hitchhikers Guide to the Internet September 1989
Krol [Page 20] RFC 1118 The Hitchhikers Guide to the Internet September 1989
RFC-1011 Official Internet Protocols
RFC-1012 Bibliography of Request for Comments 1 through 999
RFC-1034 Domain Names - Concepts and Facilities
RFC-1035 Domain Names - Implementation
RFC-1042 A Standard for the Transmission of IP
Datagrams over IEEE 802 Networks
RFC-1048 BOOTP Vendor Information Extensions
RFC-1058 Routing Information Protocol
RFC-1059 Network Time Protocol (NTP)
RFC-1065 Structure and Identification of
Management Information for TCP/IP-based internets
RFC-1066 Management Information Base for Network
Management of TCP/IP-based internets
RFC-1084 BOOTP Vendor Information Extensions
RFC-1087 Ethics and the Internet
RFC-1095 The Common Management Information
Services and Protocol over TCP/IP (CMOT)
RFC-1098 A Simple Network Management Protocol (SNMP)
RFC-1100 IAB Official Protocol Standards
RFC-1101 DNS Encoding of Network Names and Other Types
RFC-1112 Host Extensions for IP Multicasting
RFC-1117 Internet Numbers
RFC-1011 Official Internet Protocols RFC-1012 Bibliography of Request for Comments 1 through 999 RFC-1034 Domain Names - Concepts and Facilities RFC-1035 Domain Names - Implementation RFC-1042 A Standard for the Transmission of IP Datagrams over IEEE 802 Networks RFC-1048 BOOTP Vendor Information Extensions RFC-1058 Routing Information Protocol RFC-1059 Network Time Protocol (NTP) RFC-1065 Structure and Identification of Management Information for TCP/IP-based internets RFC-1066 Management Information Base for Network Management of TCP/IP-based internets RFC-1084 BOOTP Vendor Information Extensions RFC-1087 Ethics and the Internet RFC-1095 The Common Management Information Services and Protocol over TCP/IP (CMOT) RFC-1098 A Simple Network Management Protocol (SNMP) RFC-1100 IAB Official Protocol Standards RFC-1101 DNS Encoding of Network Names and Other Types RFC-1112 Host Extensions for IP Multicasting RFC-1117 Internet Numbers
Note: This list is a portion of a list of RFC's by topic that may be retrieved from the NIC under NETINFO:RFC-SETS.TXT (anonymous FTP, of course).
Note: This list is a portion of a list of RFC's by topic that may be retrieved from the NIC under NETINFO:RFC-SETS.TXT (anonymous FTP, of course).
The following list is not necessary for connection to the Internet, but is useful in understanding the domain system, mail system, and gateways:
The following list is not necessary for connection to the Internet, but is useful in understanding the domain system, mail system, and gateways:
RFC-974 Mail Routing and the Domain System RFC-1009 Requirements for Internet Gateways RFC-1034 Domain Names - Concepts and Facilities RFC-1035 Domain Names - Implementation and Specification RFC-1101 DNS Encoding of Network Names and Other Types
RFC-974 Mail Routing and the Domain System RFC-1009 Requirements for Internet Gateways RFC-1034 Domain Names - Concepts and Facilities RFC-1035 Domain Names - Implementation and Specification RFC-1101 DNS Encoding of Network Names and Other Types
Krol [Page 21] RFC 1118 The Hitchhikers Guide to the Internet September 1989
Krol [Page 21] RFC 1118 The Hitchhikers Guide to the Internet September 1989
Appendix C - Contact Points for Network Information ---------------------------------------------------
Appendix C - Contact Points for Network Information ---------------------------------------------------
Network Information Center (NIC)
Network Information Center (NIC)
DDN Network Information Center
SRI International, Room EJ291
333 Ravenswood Avenue
Menlo Park, CA 94025
(800) 235-3155 or (415) 859-3695
DDN Network Information Center SRI International, Room EJ291 333 Ravenswood Avenue Menlo Park, CA 94025 (800) 235-3155 or (415) 859-3695
NIC@NIC.DDN.MIL
NIC@NIC.DDN.MIL
NSF Network Service Center (NNSC)
NSF Network Service Center (NNSC)
NNSC
BBN Systems and Technology Corporation
10 Moulton St.
Cambridge, MA 02238
(617) 873-3400
NNSC BBN Systems and Technology Corporation 10 Moulton St. Cambridge, MA 02238 (617) 873-3400
NNSC@NNSC.NSF.NET
NNSC@NNSC.NSF.NET
NSF Network Information Service (NIS)
NSF Network Information Service (NIS)
NIS
Merit Inc.
University of Michigan
1075 Beal Avenue
Ann Arbor, MI 48109
(313) 763-4897
NIS Merit Inc. University of Michigan 1075 Beal Avenue Ann Arbor, MI 48109 (313) 763-4897
INFO@NIS.NSF.NET
INFO@NIS.NSF.NET
CIC
CIC
CSNET Coordination and Information Center
Bolt Beranek and Newman Inc.
10 Moulton Street
Cambridge, MA 02238
(617) 873-2777
CSNET Coordination and Information Center Bolt Beranek and Newman Inc. 10 Moulton Street Cambridge, MA 02238 (617) 873-2777
INFO@SH.CS.NET
INFO@SH.CS.NET
Krol [Page 22] RFC 1118 The Hitchhikers Guide to the Internet September 1989
Krol [Page 22] RFC 1118 The Hitchhikers Guide to the Internet September 1989
Glossary --------
Glossary --------
autonomous system
autonomous system
A set of gateways under a single administrative control and using
compatible and consistent routing procedures. Generally speaking,
the gateways run by a particular organization. Since a gateway is
connected to two (or more) networks it is not usually correct to
say that a gateway is in a network. For example, the gateways
that connect regional networks to the NSF Backbone network are run
by Merit and form an autonomous system. Another example, the
gateways that connect campuses to NYSERNET are run by NYSER and
form an autonomous system.
A set of gateways under a single administrative control and using compatible and consistent routing procedures. Generally speaking, the gateways run by a particular organization. Since a gateway is connected to two (or more) networks it is not usually correct to say that a gateway is in a network. For example, the gateways that connect regional networks to the NSF Backbone network are run by Merit and form an autonomous system. Another example, the gateways that connect campuses to NYSERNET are run by NYSER and form an autonomous system.
core gateway
core gateway
The innermost gateways of the Internet. These gateways have a
total picture of the reachability to all networks known to the
Internet. They then redistribute reachability information to
their neighbor gateways speaking EGP. It is from them your EGP
agent (there is one acting for you somewhere if you can reach the
core of the Internet) finds out it can reach all the nets on the
Internet. Which is then passed to you via Hello, gated, RIP. The
core gateways mostly connect campuses to the ARPANET, or
interconnect the ARPANET and the MILNET, and are run by BBN.
インターネットの最も奥深いゲートウェイ。 これらのゲートウェイで、すべてのネットワークへの可到達性の総絵をインターネットに知っています。 そして、彼らはそれらの隣人ゲートウェイへのEGPを話す可到達性情報を再配付します。 それらから、あなたのEGPエージェント(あなたがインターネットのコアに達することができるならどこかであなたの代理をする1つがある)が、インターネットのすべてのネットに達することができるのを見つけるということです。 次に、外出を禁止されたHelloを通したあなたへのRIPは渡されます。 コアゲートウェイは、アルパネットにキャンパスをほとんどつなげるか、またはアルパネットとMILNETとインタコネクトして、BBNによって動かされます。
count to infinity
無限で数えてください。
The symptom of a routing problem where routing information is
passed in a circular manner through multiple gateways. Each
gateway increments the metric appropriately and passes it on. As
the metric is passed around the loop, it increments to ever
increasing values until it reaches the maximum for the routing
protocol being used, which typically denotes a link outage.
ルーティング問題の兆候は複数のゲートウェイを通して情報を発送するのを円形の方法で流れます。 各ゲートウェイは、適切にメートル法を増加して、それを伝えます。 メートル法が輪の周りで通過されるのに従って、それは増加する値をかつてリンク供給停止を通常指示する使用されるルーティング・プロトコルのための最大に達するまで増加します。
hold down
抑制
When a router discovers a path in the network has gone down
announcing that that path is down for a minimum amount of time
(usually at least two minutes). This allows for the propagation
of the routing information across the network and prevents the
formation of routing loops.
ルータが、ネットワークにおける経路が行ったと発見したら、その経路が最小の時間(通常少なくとも2分)あると発表しながら、ダウンしてください。 これは、ネットワークの向こう側にルーティング情報の伝播を考慮して、ルーティング輪の構成を防ぎます。
split horizon
分裂地平線
When a router (or group of routers working in consort) accept
routing information from multiple external networks, but do not
ルータ(または、配偶者で働いているルータのグループ)が受け入れるとき、しかし、複数の外部のネットワークから情報を発送するのはそうしません。
Krol [Page 23] RFC 1118 The Hitchhikers Guide to the Internet September 1989
ヒッチハイカーが1989年9月にインターネットに誘導するクロール[23ページ]RFC1118
pass on information learned from one external network to any
others. This is an attempt to prevent bogus routes to a network
from being propagated because of gossip or counting to infinity.
1つの外部のネットワークからどんな他のものまでも学習された情報を伝えてください。 これはネットワークへのにせのルートがゴシップのために伝播されるか、または無限で重要であることを防ぐ試みです。
DDN
DDN
Defense Data Network the collective name for the ARPANET and
MILNET. Used frequently because although they are seperate
networks the operational and informational foci are the same.
ディフェンスData Network、アルパネットとMILNETのための集合名。 それらがseperateネットワークですが、操作上の、そして、情報の増殖巣が同じであるので、頻繁に使用されます。
Security Considerations
セキュリティ問題
Security and privacy protection is a serious matter and too often nothing is done about it. There are some known security bugs (especially in access control) in BSD Unix and in some implementations of network services. The hitchhikers guide does not discuss these issues (too bad).
セキュリティとプライバシー保護は重大な問題です、そして、あまりにも頻繁に、それに関して何もしません。 BSD Unixとネットワーク・サービスのいくつかの実現にはいくつかの知られているセキュリティバグ(特にアクセス管理における)があります。 ヒッチハイカーガイドはこれらの問題(残念な)について議論しません。
Author's Address
作者のアドレス
Ed Krol University of Illinois 195 DCL 1304 West Springfield Avenue Urbana, IL 61801-4399
西スプリングフィールドAvenueアーバナ、エドクロールイリノイ大学195DCL1304IL61801-4399
Phone: (217) 333-7886
以下に電話をしてください。 (217) 333-7886
EMail: Krol@UXC.CSO.UIUC.EDU
メール: Krol@UXC.CSO.UIUC.EDU
Krol [Page 24]
クロール[24ページ]
一覧
スポンサーリンク
