RFC1127 日本語訳
1127 Perspective on the Host Requirements RFCs. R.T. Braden. October 1989. (Format: TXT=41267 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group R. Braden
Request for Comments: 1127 ISI
October 1989
コメントを求めるワーキンググループR.ブレーデン要求をネットワークでつないでください: 1127 ISI1989年10月
A Perspective on the Host Requirements RFCs
ホスト要件RFCsの上の見解
Status of This Memo
このメモの状態
This RFC is for information only; it does not constitute a standard, draft standard, or proposed standard, and it does not define a protocol. Distribution of this memo is unlimited.
このRFCは情報だけのためのものです。 それは規格、草稿規格、または提案された標準を構成しません、そして、プロトコルを定義しません。 このメモの分配は無制限です。
Summary
概要
This RFC contains an informal summary of the discussions and conclusions of the IETF Working Group on Host Requirements while it was preparing the Host Requirements RFCs. This summary has several purposes: (1) to inform the community of host protocol issues that need further work; (2) to preserve some history and context as a starting point for future revision efforts; and (3) to provide some insight into the results of the Host Requirements effort.
Host Requirements RFCsを準備していた間、このRFCは議論の非公式の概要とHost RequirementsにおけるIETF作業部会の結論を含んでいます。 この概要には、いくつかの目的があります: (1) ホストプロトコル問題について共同体に知らせるために、それはさらに働かなければなりません。 (2) 今後の改正の努力のための出発点として何らかの歴史と文脈を保持するために。 そして、Host Requirementsの努力の結果に関する何らかの洞察を提供する(3)。
1. INTRODUCTION
1. 序論
A working group of the Internet Engineering Task Force (IETF) has recently completed and published a monumental standards document on software requirements for Internet hosts [RFC-1122, RFC-1123]. This document has been published as two RFC's: "Requirements for Internet Hosts -- Communication Layers", referred to here as "HR-CL", and "Requirements for Internet Hosts -- Application and Support", referred to here as "HR-AS". Together, we refer to them as the Host Requirements RFCs, or "HR RFCs".
インターネット・エンジニアリング・タスク・フォース(IETF)のワーキンググループは、最近、インターネット・ホスト[RFC-1122、RFC-1123]へのソフトウェア要件のとてつもない規格文書を完成して、発表しました。 このドキュメントは2RFCのものとして発表されました: そして、「インターネットHostsのための要件--、コミュニケーションLayers、」 ここが「時間Cl」として参照されている、「インターネットホストのための要件--、アプリケーションとサポート、」、ここが参照される、「時間、-、」 私たちはHost Requirements RFCs、または「時間RFCs」とそれらを一緒に、呼びます。
Creation of the Host Requirements document required the dedicated efforts of about 20 Internet experts, with significant contributions from another 20. The Host Requirements working group held 7 formal meetings over the past 20 months, and exchanged about 3 megabytes of electronic mail. The HR RFCs went through approximate 20 distinct drafts.
Host Requirementsドキュメントの創造はおよそ20人のインターネットの専門家のひたむきな努力を必要としました、別の20からの重要な貢献で。 Host Requirementsワーキンググループは、20カ月の過去に7つの正式なミーティングを延期して、およそ3メガバイトの電子メールを交換しました。 HR RFCsは20の大体の異なった草稿に直面していました。
This group of people struggled with a broad range of issues in host implementations of the Internet protocols, attempting to reconcile theoretical and architectural concerns with the sometimes conflicting imperatives of the real world. The present RFC recaps the results of this struggle, with the issues that were settled and those that remain for future work. This exegesis has several goals:
人々のこのグループはインターネットプロトコルのホスト導入における広範囲な問題と戦いました、本当の世界の時々闘争している命令と理論上の、そして、建築している関心を仲直りさせるのを試みて。 現在のRFCはこの戦いの結果をリキャップします、決着した問題と今後の活動のために残っているもので。 この解釈には、いくつかの目標があります:
Braden [Page 1] RFC 1127 Perspective on Host Requirements October 1989
ホスト要件1989年10月のブレーデン[1ページ]RFC1127見解
(1) to give the Internet technical community some insight into the
results of the host requirements effort;
ホスト要件の努力の結果に関する何らかの洞察をインターネット技術団体に与える(1)。
(2) to inform the community of areas that need further work; and
(2) 領域について共同体に知らせるために、それはさらに働かなければなりません。 そして
(3) to preserve some history and context of the effort as a starting
point for a future revision.
今後の改正のための出発点として努力の何らかの歴史と文脈を保持する(3)。
1.1 GOALS OF THE HOST REQUIREMENTS RFCs
1.1 ホスト要件RFCsの目標
The basic purpose of the Host Requirements RFCs is to define the requirements for Internet host software. However, the document goes far beyond a simple prescription of requirements, to include:
Host Requirements RFCsの基本的な目的はインターネット・ホストソフトウェアのための要件を定義することです。 しかしながら、ドキュメントは、以下を含むように遠くに要件の簡単な処方箋を越えます。
(a) a bibliography of the documents essential to an implementor;
(a) 作成者にとって、不可欠のドキュメントの図書目録。
(b) corrections and updates to the original standards RFC's;
(b) オリジナルのRFCの規格ものへの修正とアップデート。
(c) material to fill gaps in the previous specifications;
前の仕様に不足をいっぱいにする(c)の材料。
(d) limitations on implementation choices, where appropriate;
(d) 実現選択の適切であるところの制限
(e) clarification of important issues and the intent of the
protocols; and
(e) 切迫した課題の明確化とプロトコルの意図。 そして
(f) documentation of known solutions to recurring problems as well
as implementation hints.
(f) 実現と同様に再発問題の知られている解決のドキュメンテーションは暗示します。
Broadly speaking, the Host Requirements working group started from the following goals for Internet host software:
概して、Host Requirementsワーキンググループはインターネット・ホストソフトウェアの以下の目標から始めました:
(1) Interoperability
(1) 相互運用性
(2) Extensibility
(2) 伸展性
(3) Functionality
(3) 機能性
(4) Efficiency
(4) 効率
(5) Architectural Purity
(5) 建築純粋さ
Of these, interoperability was clearly preeminent, while architectural purity had the lowest priority. It is more difficult to assign relative importance to extensibility, functionality, and efficiency, as it varied from one topic to another.
これらでは、相互運用性は明確に抜群でしたが、建築純粋さに、最も低い優先度がありました。 伸展性、機能性、および効率に相対的な重要性を割り当てるのは、より難しいです、1つの話題から別のものに異なったので。
At a more technical level, the working group pursued a set of general goals that included the following:
より技術的なレベルでは、ワーキンググループは以下を含んでいた1セットの一般的な目標を追求しました:
Braden [Page 2] RFC 1127 Perspective on Host Requirements October 1989
ホスト要件1989年10月のブレーデン[2ページ]RFC1127見解
* Discourage hosts from unexpectedly acting as gateways.
* ホストがゲートウェイとして不意に務めるのを思いとどまってください。
* Discourage the use of bad IP addresses.
* 悪いIPアドレスの使用に水をさしてください。
* Eliminate broadcast storms.
* ブロードキャスト・ストームを排除してください。
* Discourage gratuitous Address Mask Reply messages.
* 無料のAddress Mask Replyメッセージに水をさしてください。
* Facilitate the use IP Type-of-Service for routing and queueing.
* 使用を容易にしてください。ルーティングと待ち行列のためのサービスのIP Type。
* Encourage implementations of IP multicasting.
* IPマルチキャスティングの実現を奨励してください。
* Encourage TCP connection robustness.
* TCP接続丈夫さを奨励してください。
* Encourage (mandate!) implementation of known TCP performance
enhancements.
* 知られているTCPパフォーマンス強化の(命令!)実現を奨励してください。
* Encourage user interfaces that support the full capabilities of
the protocols.
* プロトコルの完全な能力を支持するユーザインタフェースを奨励してください。
* Encourage more complete implementations of FTP.
* FTPの、より完全な実現を奨励してください。
* Encourage robust mail delivery
* 体力を要している郵便配達を奨励してください。
* Discourage the source-routing of mail in the Internet.
* インターネットでメールのソースルーティングに水をさしてください。
* Encourage error logging.
* エラー・ロギングを奨励してください。
In addition to these general technical goals, the working group decided to discourage the use of certain protocol features: e.g., the IP Stream Id option, ICMP Information Request and Reply messages, the RFC-795 TOS mappings, WKS records in the Domain Name System, and FTP Page structure.
これらの一般的な技術的な目標に加えて、ワーキンググループは、あるプロトコル機能の使用に水をさしていると決めました: 例えば、IP Stream Idオプション、情報のRequestとReplyメッセージ、RFC-795 TOSマッピング、WKSがドメインネームシステムに記録するICMP、およびFTPページ構造。
The HR RFC tries to deal only with the software implementation, not with the way in which that software is configured and applied. There are a number of requirements on Internet hosts that were omitted from the HR RFC as administrative or configuration issues.
HR RFCはソフトウェア実行だけに対処しようとします、そのソフトウェアが構成されて、適用されるいずれの方法でも、そうしません。 管理としてHR RFCから省略されたインターネット・ホストか構成問題に関する多くの要件があります。
The HR RFCs contain many, many detailed requirements and clarifications that are straightforward and (almost) non- controversial.
HR RFCsは多くの詳細な要件と簡単で(ほとんど)非論議を呼んだ明確化を含んでいます。
Indeed, many of these are simply restatements or reinforcement of requirements that are already explicit or implicit in the original standards RFC's. Some more cynical members of the working group refer to these as "Read The Manual" provisions. However, they were included in the HR RFCs because at least one implementation has
Indeed, many of these are simply restatements or reinforcement of requirements that are already explicit or implicit in the original standards RFC's. ワーキンググループのそれ以上のシニカルなメンバーが「マニュアルを読んでください」という条項にこれらについて言及します。 しかしながら、それらは、少なくとも1つの実現が含まれていたので、HR RFCsに含まれていました。
Braden [Page 3] RFC 1127 Perspective on Host Requirements October 1989
ホスト要件1989年10月のブレーデン[3ページ]RFC1127見解
failed to abide by these requirements. In addition, many provisions of the HR RFCs are simply applications of Jon Postel's Robustness Principle [1.2.2 in either RFC].
これらの要件を守りませんでした。 中、さらに、HR RFCsに関する多くの条項が単にジョン・ポステルのRobustness Principleのアプリケーションである、[1.2、.2、RFC]
However, not all issues were so easy; the working group struggled with a number of deep and controversial technical issues. Where the result was a reasonable consensus, then definite, firm recommendations and requirements resulted. We list these settled issues in Section 2. Section 2 also lists a number of areas where the HR RFCs fill gaping holes in the current specifications by giving extended discussions of particular issues.
しかしながら、すべての問題がどんなそれほど簡単であったというわけではありません。 ワーキンググループは多くの深くて論議を呼んだ専門的な問題と戦いました。 そして、結果が妥当なコンセンサスであったところでは、明確で、堅い推薦と要件は結果として生じました。 私たちはセクション2のこれらの解決された問題を記載します。 また、セクション2はHR RFCsが現在の仕様に特定の問題の長い討論を与えることによって大きい穴をいっぱいにする多くの領域を記載します。
However, in some other cases the working group was unable to reach a crisp decision or even a reasonable consensus; we list these open issues in Section 3. Future discussion is needed to ascertain which of these issues really do have "right answers", and which can reasonably be left as implementation choices. Section 4 contains some other areas that the working group did not tackle but which need further work outside the context of the HR RFCs (although the outcome may be reflected in a future revision). Finally, Appendix I lists specific issues for consideration by a future HR RFC revision effort, while Appendix II lists the issues that are relevant to a revision of the Gateway Requirements RFC.
しかしながら、ある他の場合では、ワーキンググループははっきりした決定か妥当なコンセンサスにさえ達することができませんでした。 私たちはセクション3のこれらの未解決の問題を記載します。 今後の議論が、これらの問題のどれに「正しい答」が本当にあるか、そして、実現選択として合理的にどれは残すことができるかを確かめるのに必要です。 セクション4はワーキンググループが取り組みませんでしたが、HR RFCsの文脈の外でさらなる仕事を必要とするある他の領域を含みます(結果は今後の改正に反映されるかもしれませんが)。 最終的に、Appendix Iは考慮のために今後のHR RFC改正の努力で特定の問題を記載します、Appendix IIはゲートウェイRequirements RFCの改正に関連している問題を記載しますが。
It should be noted that this categorization of issues is imperfect; a few issues appear (legitimately) in more than one category.
問題のこの分類が不完全であることに注意されるべきです。 いくつかの問題が1つ以上のカテゴリに現れます(合法的に)。
For brevity, we do not attempt to define all the terminology or explain all the concepts mentioned here. For those cases where further clarification is needed, we include (in square brackets) references to the corresponding sections of the HR RFCs.
簡潔さのために、私たちは、すべての用語を定義するか、またはここに言及されたすべての概念について説明するのを試みません。 さらなる明確化が必要であるそれらのケースのために、私たちはHR RFCsの該当箇所の指示するものを入れます(角括弧で)。
2. SETTLED ISSUES
2. 解決された問題
Here are the areas in which the Host Requirements working group was able to reach a consensus and take a definite stand.
ここに、Host Requirementsワーキンググループがコンセンサスに達して、明確な態度を取ることができた領域があります。
- ARP Cache Management [CL 2.3.2.1]
- ARPキャッシュ管理[Cl2.3.2、.1]
Require a mechanism to flush out-of-date ARP cache entries.
メカニズムを必要として、時代遅れなARPキャッシュエントリーを洗い流してください。
- Queueing packets in ARP [CL 2.3.2.2]
- ARPの待ち行列パケット[Cl2.3.2、.2]
Recommend that ARP queue unresolved packet(s) in the link layer.
ARPがリンクレイヤの中に未定のパケットを列に並ばせることを勧めてください。
- Ethernet/802.3 Interoperability [CL 2.3.3]
- イーサネット/802.3相互運用性[Cl2.3.3]
Impose interoperability requirements for Ethernet and IEEE 802.3
イーサネットとIEEE802.3のための相互運用性要件を課してください。
Braden [Page 4] RFC 1127 Perspective on Host Requirements October 1989
ホスト要件1989年10月のブレーデン[4ページ]RFC1127見解
encapsulation.
カプセル化。
- Broadcast Storms [CL 2.4, 3.2.2]
- ブロードキャスト・ストーム[Cl2.4、3.2.2]
Require many provisions to prevent broadcast storms.
多くの条項を必要として、ブロードキャスト・ストームを防いでください。
In particular, require that the link-layer driver pass a flag to
the IP layer to indicate if a packet was received via a link-
layer broadcast, and require that this flag be used by the IP
layer.
リンクレイヤドライバーがパケットがリンク層の放送で受け取られたかどうかを示すためにIP層に旗を渡すのを特に、必要であってください、そして、この旗がIP層によって使用されるのを必要であってください。
- Bad IP addresses
- 悪いIPアドレス
Include numerous provisions to discourage the use of bad IP
addresses.
悪いIPアドレスの使用に水をさしているために多数の条項を含めてください。
- Address Mask Replies [CL 3.2.2.9]
- アドレスマスク回答[Cl3.2.2、.9]
Discourage gratuitous ICMP Address Mask Reply messages.
無料のICMP Address Mask Replyメッセージに水をさしてください。
- Type-of-Service
- サービスのタイプ
Include various requirements on IP, transport, and application
layers to make Type-of-Service (TOS) useful.
IPに関する様々な要件、輸送、および応用層を含めて、サービスのType(TOS)を役に立つようにしてください。
- Time-to-Live [CL 3.2.1.7]
- 生きる時間[Cl3.2.1、.7]
Require that Time-to-Live (TTL) be configurable.
生きるTime(TTL)が構成可能であることを必要であってください。
- Source Routing [CL 3.2.1.8(e)]
- ソースルート設定[Cl3.2.1.8(e)]
Require that host be able to act as originator or final
destination of a source route.
ホストが送信元経路の創始者か最終的な目的地として務めることができるのを必要であってください。
- IP Multicasting [CL 3.3.7]
- IPマルチキャスティング[Cl3.3.7]
Encourage implementation of local IP multicasting.
ローカルアイピーマルチキャスティングの実現を奨励してください。
- Reassembly Timeout [CL 3.3.2]
- Reassemblyタイムアウト[Cl3.3.2]
Require a fixed reassembly timeout.
固定再アセンブリタイムアウトを必要としてください。
- Choosing a Source Address [CL 3.3.4.3, 3.4, 4.1.3.5, 4.2.3.7]
- ソースアドレスを選びます。[Cl、3.3 .4 .3 3.4 4.1 .3 .5、4.2、.3、.7]
Require that an application on a multihomed host be able to
either specify which local IP address to use for a new TCP
connection or UDP request, or else leave the local address
"wild" and let the IP layer pick one.
IP層が「マルチ-家へ帰」っているホストにおけるアプリケーションで新しいTCP接続に使用するアドレスかUDPがどのローカルアイピーを要求するかを指定するか、ローカルアドレスを「ワイルドな」状態でおいて、または1つを選ぶことができるのを必要であってください。
Braden [Page 5] RFC 1127 Perspective on Host Requirements October 1989
ホスト要件1989年10月のブレーデン[5ページ]RFC1127見解
- TCP Performance [CL 4.2.12.15, 4.2.3.1-4]
- TCPパフォーマンス[Cl、4.2 .12 .15 4.2.3.1-4]
Require TCP performance improvements.
TCP性能改良を必要としてください。
- TCP Connection Robustness [CL 4.2.3.5, 4.2.3.9]
- TCP接続丈夫さ[Cl、4.2 .3 .5、4.2、.3、.9]
Encourage robustness of TCP connections.
TCP接続の丈夫さを奨励してください。
- TCP Window Shrinking [CL 4.2.2.16]
- TCP窓の萎縮[Cl4.2.2、.16]
Discourage the shrinking of TCP windows from the right.
右からのTCPの窓の萎縮をがっかりさせてください。
- Dotted-Decimal Host Numbers [AS 2.1]
- ドット付き10進法ホスト番号[2.1としての]
Recommend that applications be able to accept dotted-decimal
host numbers in place of host names.
アプリケーションがホスト名に代わってドット付き10進法ホスト番号を受け入れることができることを勧めてください。
- Telnet End-of-Line [AS 3.3.1]
- telnet行末[3.3、.1]
Include compatibility requirements for Telnet end-of-line.
Telnet行末のための互換性要件を含めてください。
- Minimal FTP [AS 4.1.2.13]
- 最小量のFTP[4.1、.2、.13]
Enlarge the minimum FTP implementation.
最小のFTP実現を拡大してください。
- Robust Mail Delivery [AS 5.3.2, 5.3.4, 6.1.3.4]
- 体力を要している郵便配達[5.3 .2 5.3 .4、6.1、.3、.4]
Recommend the use of long timeouts and of alternative addresses
for multihomed hosts, to obtain robust mail delivery.
長いタイムアウトと代替アドレスの「マルチ-家へ帰」っているホストの使用を推薦して、体力を要している郵便配達を得てください。
- Source-Routing of Mail [AS 5.2.6, 5.2.16, 5.2.19]
- メールのソースルート設定[5.2 .6 5.2 .16、5.2、.19]
Discourage the use of source routes for delivering mail. (This
was one of the few cases where the working group opted for the
architecturally pure resolution of an issue.)
送信元経路のメールを配達する使用に水をさしてください。 (これはワーキンググループが問題の建築上純粋な解決を選んだわずかなケースの1つでした。)
- Fully-Qualified Domain Names [AS 5.2.18]
- 完全修飾ドメイン名[5.2、.18]
Require the use of fully-qualified domain names in RFC-822
addresses.
RFC-822アドレスにおける完全修飾ドメイン名の使用を必要としてください。
- Domain Name System Required [AS 6.1.1]
- ドメインネームシステムが必要です。[6.1、.1]
Require that hosts implement the Domain Name System (DNS).
ホストがドメインネームシステム(DNS)を実行するのを必要であってください。
- WKS Records Detracted [AS 2.2, 5.2.12, 6.1.3.6]
- WKS記録はそらされました。[2.2 5.2 .12、6.1、.3、.6]
Recommend against using WKS records from DNS.
使用に対してWKSがDNSから記録することを勧めてください。
Braden [Page 6] RFC 1127 Perspective on Host Requirements October 1989
ホスト要件1989年10月のブレーデン[6ページ]RFC1127見解
- UDP Preferred for DNS Queries [AS 6.1.2.4, 6.1.3.2]
- DNS質問のために好まれたUDP[6.1 .2 .4、6.1、.3、.2]
Require that UDP be preferred over TCP for DNS queries.
UDPがDNS質問のためにTCPより好まれるのを必要であってください。
- DNS Negative Caching [AS 6.1.3.3]
- DNSの否定的キャッシュ[6.1、.3、.3]
Recommend that DNS name servers and resolvers cache negative
responses and temporary failures.
DNSネームサーバとレゾルバが否定応答と一時障害をキャッシュすることを勧めてください。
Finally, here is a list of areas in which the HR RFCs provide extended discussion of issues that have been inadequately documented in the past.
最終的に、ここに、HR RFCsが過去に不十分に記録された問題の長い討論を提供する領域のリストがあります。
- ARP cache handling [CL 2.3.2.1]
- ARPキャッシュ取り扱い[Cl2.3.2、.1]
- Trailer encapsulation [CL 2.3.1]
- トレーラカプセル化[Cl2.3.1]
- Dead gateway detection algorithms [CL 3.3.1.4]
- 停止ゲートウェイ検出アルゴリズム[Cl3.3.1、.4]
- IP multihoming models [CL 3.3.4]
- IPマルチホーミングモデル[Cl3.3.4]
(Note that this topic is also one of the significant contentious
issues; see the next section.)
(また、この話題が重要な論争を起こす問題の1つであることに注意してください; 次のセクションを見てください。)
- Maximum transmission unit (MTU and transport-layer maximum-
segment size (MSS) issues [CL 3.3.2, 3.3.3, 3.4, 4.1.4,
4.2.2.6]
- マキシマム・トランスミッション・ユニット、(MTUとトランスポート層の最大のセグメントサイズ(MSS)は発行します。[Cl、3.3 .2 3.3 .3 3.4 4.1 .4、4.2、.2、.6]
- TCP silly-window syndrome (SWS) avoidance algorithms
[CL 4.2.3.3, 4.2.3.4]
- TCP愚かな窓のシンドローム(SWS)回避アルゴリズム[Cl、4.2 .3 .3、4.2、.3、.4]
- Telnet end-of-line issues [AS 3.3.1]
- telnet行末問題[3.3、.1]
- Telnet interrupt/SYNCH usage [AS 3.2.4]
- telnet中断/SYNCH用法[3.2、.4]
- FTP restart facility [AS 4.1.3.4]
- FTPリスタート機能[4.1、.3、.4]
- DNS efficiency issues [AS 6.1.3.3]
- DNS効率問題[6.1、.3、.3]
- DNS user interface: aliases and search lists [AS 6.1.4.3]
- DNSユーザーインタフェース: 別名と検索リスト[6.1、.4、.3]
There are some other areas where the working group tried to produce a more extended discussion but was not totally successful; one example is error logging (see Appendix I below).
ある他の領域がワーキンググループが、より拡張している議論を起こそうとしますが、完全にうまくいったというわけではないところにあります。 ある例がエラー・ロギング(以下のAppendix Iを見る)です。
Braden [Page 7] RFC 1127 Perspective on Host Requirements October 1989
ホスト要件1989年10月のブレーデン[7ページ]RFC1127見解
3. OPEN ISSUES
3. 未解決の問題
For some issues, the disagreement was so serious that the working group was unable to reach a consensus. In each case, some spoke for MUST or SHOULD, while others spoke with equal fervor for MUST NOT or SHOULD NOT. As a result, the HR RFCs try to summarize the differing viewpoints but take no stand; the corresponding requirements are given as MAY or OPTIONAL. The most notorious of these contentious issues are as follows.
いくつかの問題において、不一致が非常に重大であったので、ワーキンググループはコンセンサスに達することができませんでした。 その都度、或るものが代弁した、SHOULD、等しい熱情をもって他のものスポークをゆったり過ごしてください、NOTかSHOULD NOTがそうしなければなりません。 その結果、HR RFCsは異なった観点をまとめますが、態度を全く取らないようにします。 5月かOPTIONALとして対応する要件を与えます。 これらの論争を起こす問題で最も悪名高いのは以下の通りです。
- Hosts forwarding source-routed datagrams, even though the hosts
are not otherwise acting as gateways [CL 3.3.5]
- そうでなければ、ホストがゲートウェイとして務めていませんが、ソースによって発送されたデータグラムを進めるホスト[Cl3.3.5]
- The multihoming model [CL 3.3.4]
- マルチホーミングモデル[Cl3.3.4]
- ICMP Echo Requests to a broadcast or multicast address
[CL 3.2.2.6]
- 放送かマルチキャストアドレスへのICMP Echo Requests[Cl3.2.2、.6]
- Host-only route caching [CL 3.3.1.3]
- ホストだけルートキャッシュ[Cl3.3.1、.3]
- Host wiretapping routing protocols [CL 3.3.1.4]
- ルーティング・プロトコルを盗聴しているホスト[Cl3.3.1、.4]
- TCP sending an ACK when it receives a segment that appears to be
out-of-order [CL 4.2.2.21]
- それが故障しているように見えるセグメントを受けるときACKを送るTCP[Cl4.2.2、.21]
There was another set of controversial issues for which the HR RFCs did take a compromise stand, to allow the disputed functions but circumscribe their use. In many of these cases, there were one or more significant voices for banning the feature altogether.
議論された機能を許容しますが、彼らの使用を外接させるように、HR RFCsが妥協態度を取ったもう1セットの論争中の問題がありました。 これらの場合の多くには、全体で特徴を禁止するための1回以上の重要な声がありました。
- Host acting as gateways [CL 3.1]
- ゲートウェイとしてのホスト芝居[Cl3.1]
- Trailer encapsulation [CL 2.3.1]
- トレーラカプセル化[Cl2.3.1]
- Delayed TCP acknowledgments [CL 4.2.3.2]
- 遅れたTCP承認[Cl4.2.3、.2]
- TCP Keep-alives [CL 4.2.3.6]
- TCP生活費アリフ[Cl4.2.3、.6]
- Ignoring UDP checksums [CL 4.1.3.4]
- UDPチェックサムを無視します。[Cl4.1.3、.4]
- Telnet Go-Aheads [AS 3.2.2]
- telnet開始許可[3.2、.2]
- Allowing 8-bit data in Telnet NVT mode [AS 3.2.5]
- Telnet NVTモードによる8ビットのデータを許容します。[3.2、.5]
Braden [Page 8] RFC 1127 Perspective on Host Requirements October 1989
ホスト要件1989年10月のブレーデン[8ページ]RFC1127見解
4. OTHER FUTURE WORK
4. 他の今後の活動
General Issues:
一般答弁:
(1) Host Initialization Procedures
(1) ホスト初期設定手順
When a host system boots or otherwise initializes, it needs
certain network configuration information in order to communicate;
e.g., its own IP address(es) and address mask(s). In the case of
a diskless workstation, obtaining this information is an essential
part of the booting process.
システムがブートするか、またはそうでなければ初期化するホストであり、交信するためにあるネットワーク設定情報を必要とすると。 例えば、自分自身のIPは(es)とアドレスマスクを扱います。 ディスクレスワークステーションの場合では、この情報を得るのは、穂ばらみプロセスの不可欠の部分です。
The ICMP Address Mask messages and the RARP (Reverse ARP) protocol
each provide individual pieces of configuration information. The
working group felt that such piecemeal solutions are a mistake,
and that a comprehensive approach to initialization would result
in a uniform mechanism to provide all the required configuration
information at once. The HR working group recommends that a new
working group be established to develop a unified approach to
system initialization.
ICMP Address MaskメッセージとRARP(ARPを逆にする)プロトコルはそれぞれ個体に関する設定情報を提供します。 ワーキンググループは、すぐにすべての必要な設定情報を提供するためにそのようなばらばらのソリューションが誤りであり、初期化への包括的なアプローチが一定のメカニズムをもたらすと感じました。 HRワーキンググループは、新しいワーキンググループがシステム初期化への統一されたアプローチを開発するために設立されることを勧めます。
(2) Configuration Options
(2) 設定オプション
Vendors, users, and network administrators all want host software
that is "plug-and-play". Unfortunately, the working group was
often forced to require additional configuration parameters to
satisfy interoperability, functionality, and/or efficiency needs
[1.2.4 in either RFC]. The working group was fully aware of the
drawbacks of configuration parameters, but based upon extensive
experience with existing implementations, it felt that the
flexibility was sometimes more important than installation
simplicity.
ベンダー、ユーザ、およびネットワーク管理者は皆、「プラグアンドプレイ」であるホストソフトウェアが欲しいです。 中、残念ながら、ワーキンググループが相互運用性、機能性、そして/または、効率需要を満たすためにしばしばやむを得ず追加設定パラメータを必要とした、[1.2、.4、RFC] ワーキンググループが設定パラメータの欠点を百も承知していますが、既存の実装の広範囲の経験に基づいていた、それは柔軟性がインストールの簡単さより時々重要であると感じました。
Some of the configuration parameters are forced for
interoperability with earlier, incorrect implementations. Very
little can be done to ease this problem, although retirement of
the offending systems will gradually solve it. However, it would
be desirable to re-examine the other required configuration
options, in an attempt to develop ways to eliminate some of them.
設定パラメータのいくつかが相互運用性のために、より早くて、不正確な実装で強制されます。 ほとんど、怒っているシステムの回収は徐々にそれを解決するでしょうが、この問題を緩和するためにすることができません。 しかしながら、他の必要な設定オプションを再検討するのは望ましいでしょう、それらのいくつかを排除する方法を開発する試みで。
Link-Layer Issues:
リンクレイヤ問題:
(2) ARP Cache Maintenance
(2) ARPキャッシュメインテナンス
"Proxy ARP" is a link-layer mechanism for IP routing, and its use
results in difficult problems in managing the ARP cache.
「プロキシARP」はIPルーティングのためのリンクレイヤメカニズムです、そして、使用はARPキャッシュを管理する際に難問をもたらします。
Even without proxy ARP, the management dynamics of the IP route
IPの力学が発送する管理のプロキシARPなしで同等です。
Braden [Page 9] RFC 1127 Perspective on Host Requirements October 1989
ホスト要件1989年10月のブレーデン[9ページ]RFC1127見解
cache interact in subtle ways with transport-layer dynamics;
introducing routing via proxy ARP brings a third protocol layer
into the problem, complicating the inter-layer dynamics still
further.
キャッシュはそれとなくトランスポート層力学と対話します。 プロキシARPを通してルーティングを導入すると、まださらに相互層の力学を複雑にしていて、3番目のプロトコル層は問題に運び込みます。
The algorithms for maintaining the ARP cache need to be studied
and experimented with, to create more complete and explicit
algorithms and requirements.
ARPキャッシュを維持するためのアルゴリズムは、より完全で明白なアルゴリズムと要件を作成するために研究されて、実験される必要があります。
(3) FDDI Bit-order in MAC addresses
(3) MACアドレスにおけるFDDI Bit-オーダー
On IEEE 802.3 or 802.4 LAN, the MAC address in the header uses the
same bit-ordering as transmission of the address as data. On
802.5 and FDDI networks, however, the MAC address in the header is
in a different bit-ordering from the equivalent 6 bytes sent as
data. This will make it hard to do MAC-level bridging between
FDDI and 802.3 LAN's, for example, although gateways (IP routers)
can still be used.
IEEE802.3か802.4LANでは、ヘッダーのMACアドレスはデータとしてのアドレスの送信と同じビット注文を使用します。 しかしながら、802.5とFDDIネットワークに、データとして送られた同等物からのビット注文異なった6バイトにはヘッダーのMACアドレスがあります。 これで、まだ、ゲートウェイ(IPルータ)を使用できますが、例えば、FDDIと802.3の間のMAC平らなブリッジすることのようにLANをするのは困難になるでしょう。
The working group concluded that this is a serious but subtle
problem with no obvious fix, and that resolving it was beyond the
scope of the HR working group.
ワーキンググループはこれが明白なフィックスがなければ重大な、しかし、微妙な問題であり、それを決議するのがHRワーキンググループの範囲を超えていたと結論を下しました。
IP-Layer Issues
IP-層の問題
(4) Dead Gateway Detection
(4) 停止ゲートウェイ検出
A fundamental requirement for a host is to be able to detect when
the first-hop gateway has failed. The early TCP/IP
experimentation was based on the ARPANET, which provided explicit
notification of gateway failure; as a result, dead gateway
detection algorithms were not much considered at that time. The
very general guidelines presented by Dave Clark [RFC-816] are
inadequate for implementors. The first attempt at applying these
guidelines was the introduction of universal gateway pinging by
TOPS-20 systems; this quickly proved to be a major generator of
ARPANET traffic, and was squelched. The most widely used
implementation of the Internet protocols, 4.2BSD, solved the
problem in an extra-architectural manner, by letting the host
wiretap the gateway routing protocol (RIP). As a result of this
history, the HR working group was faced with an absence of
documentated techniques that a host conforming to the Internet
architecture could use to detect dead gateways.
ホストにとって、基本的な要件は最初に、ホップゲートウェイがいつ失敗したかを検出することであることができます。 早めのTCP/IP実験はアルパネットに基づきました。(それは、ゲートウェイの故障の明白な通知を提供しました)。 その結果、停止ゲートウェイ検出アルゴリズムはその時、あまり考えられませんでした。 デーブ・クラーク[RFC-816]によって提示された非常に一般的なガイドラインは作成者に不十分です。 これらのガイドラインを適用することへの最初の試みはTOPS-20システムによる普遍的なゲートウェイノッキングの導入でした。 これは、アルパネットトラフィックの主要なジェネレータであるとすぐに判明して、押しつぶされました。 インターネットプロトコルの最も広く使用された実装(4.2BSD)は付加的な建築方法で問題を解決しました、ホストにゲートウェイルーティング・プロトコル(RIP)を盗聴させることによって。 この歴史の結果、HRワーキンググループはインターネットアーキテクチャへのホストの従うのが停止ゲートウェイを検出するのに使用できたdocumentatedテクニックの欠如に直面していました。
After extensive discussion, the working group agreed on the
outline of an appropriate algorithm. A detailed algorithm was in
fact written down, to validate the discussion in the HR RFCs.
This algorithm, or a better one, should be tried experimentally
大規模な議論の後に、ワーキンググループは適切なアルゴリズムのアウトラインに同意しました。 事実上、詳細なアルゴリズムは、HR RFCsで議論を有効にするために書き留められました。 このアルゴリズム、または、より良い実験的に試みられるべきです。
Braden [Page 10] RFC 1127 Perspective on Host Requirements October 1989
ホスト要件1989年10月のブレーデン[10ページ]RFC1127見解
and documented in a new RFC.
そして、新しいRFCに記録されています。
(5) Gateway Discovery
(5) ゲートウェイ発見
A host needs to discover the IP addresses of gateways on its
connected networks. One approach, begun but not finished by
members of the HR working group, would be to define a new pair of
ICMP query messages for gateway discovery. In the future, gateway
discovery should be considered as part of the complete host
initialization problem.
ホストは、接続ネットワークでゲートウェイのIPアドレスを発見する必要があります。 HRワーキンググループのメンバーが始められましたが、終えていなかった1つのアプローチはゲートウェイ発見へのICMP質問メッセージの新しいペアを定義するだろうことです。 将来、ゲートウェイ発見は完全なホスト初期化問題の一部であるとみなされるべきです。
(6) MTU Discovery
(6) MTU発見
Members of the HR working group designed IP options that a host
could use to discover the minimum MTU of a particular Internet
path [RFC-1063]. To be useful, the Probe MTU options would have
to be implemented in all gateways, which is an obstacle to its
adoption. Code written to use these options has never been
tested. This work should be carried forward; an effective MTU
choice will become increasingly important for efficient Internet
service.
HRワーキンググループのメンバーはホストが特定のインターネット経路[RFC-1063]の最小のMTUを発見するのに使用できたIPオプションを設計しました。 役に立つように、Probe MTUオプションはすべてのゲートウェイで実装されなければならないでしょう(採用への障害です)。 これらのオプションを使用するために書かれたコードは一度もテストされたことがありません。 この仕事は進展するべきです。 有効なMTU選択はますます効率的なインターネットのサービスには重要になるでしょう。
(7) Routing Advice from Gateways
(7) ゲートウェイからのルート設定アドバイス
A working group member produced a draft specification for ICMP
messages a host could use to ask gateways for routing advice
[Lekashman]. While this is not of such pressing importance as the
issues listed previously, it deserves further consideration and
perhaps experimentation.
ワーキンググループのメンバーはホストがルーティングアドバイス[Lekashman]を求めてゲートウェイを尋ねるのに使用できたICMPメッセージのための草稿仕様を作り出しました。 これには、問題が以前に記載したようにそのようなものが重要性を押すのがありませんが、それはさらなる考慮と恐らく実験に値します。
(8) Dynamic TTL Discovery
(8) ダイナミックなTTL発見
Serious connectivity problems have resulted from host software
that has too small a TTL value built into the code. HR-CL
specifies that TTL values must be configurable, to allow TTL to be
increased if required for communication in a future Internet;
conformance with this requirement would solve the current
problems. However, configurable parameters are an operational
headache, so it has been suggested that a host could have an
algorithm to determine the TTL ("Internet diameter") dynamically.
Several algorithms have been suggested, but considerably more work
would be required to validate them. This is a lower-priority
problem than issues (4)-(6).
重大な接続性問題はコードを小さ過ぎるTTL値に組み込むホストソフトウェアから生じました。 HR-CLは、TTL値がTTLが必要なら将来のインターネットのコミュニケーションのために増強されるのを許容するために構成可能でなければならないと指定します。 この要件がある順応は現在の問題を解決するでしょう。しかしながら、構成可能なパラメタが操作上の頭痛である、したがって、ホストがダイナミックに、TTL(「インターネット直径」)を決定するアルゴリズムを持つことができたことが提案されました。 いくつかのアルゴリズムが示されましたが、かなり多くの仕事が、それらを有効にするのに必要でしょう。 これは(4)を発行するより低優先度問題です--(6)。
(9) Dynamic Discovery of Reassembly Timeout Time
(9) Reassemblyタイムアウト時間のダイナミックな発見
The maximum time for retaining a partially-reassembled datagram is
another parameter that creates a potential operational headache.
部分的に組み立て直されたデータグラムを保有するための最大の時間は潜在的操作上の頭痛を引き起こす別のパラメタです。
Braden [Page 11] RFC 1127 Perspective on Host Requirements October 1989
ホスト要件1989年10月のブレーデン[11ページ]RFC1127見解
An appropriate reassembly timeout value must balance available
reassembly buffer space against reliable reassembly. The best
value thus may depend upon the system and upon subtle delay
properties (delay dispersion) of the Internet. Again, dynamic
discovery could be desirable.
適切な再アセンブリタイムアウト価値は信頼できる再アセンブリに対して利用可能な再アセンブリバッファ領域のバランスをとらなければなりません。 その結果、最も良い値はシステムとインターネットの微妙な遅れの特性(遅れ分散)に依存するかもしれません。 一方、ダイナミックな発見は望ましいかもしれません。
(10) Type-of-Service Routing in Hosts
(10) ホストのサービスのタイプルート設定
As pointed out previously, the HR RFCs contain a number of
provisions designed to make Type-of-Service (TOS) useful. This
includes the suggestion that the route cache should have a place
or specifying the TOS of a particular route. However, host
algorithms for using TOS specifications need to be developed and
documented.
以前に指摘されるように、HR RFCsはサービスのType(TOS)を役に立つようにするように設計された多くの条項を含んでいます。 これは、経路キャッシュには場所があるべきであるという提案か特定のルートのTOSを指定するのを含んでいます。 しかしながら、TOS仕様を使用するためのホストアルゴリズムは、開発されて、記録される必要があります。
(11) Using Subnets
(11) サブネットを使用すること。
An RFC is needed to provide a thorough explanation of the
implications of subnetting for Internet protocols and for network
administration.
RFCが、サブネッティングの含意の徹底的な説明をインターネットプロトコルとネットワーク管理に提供するのに必要です。
Transport-Layer Issues:
トランスポート層問題:
(12) RST Message
(12) RSTメッセージ
It has been proposed that TCP RST (Reset) segments can contain
text to provide an explicit explanation of the reason for the
particular RST. A proposal has been drafted [CLynn].
TCP RST(リセット)セグメントが特定のRSTの理由の明白な説明を提供するテキストを含むことができるよう提案されました。提案を作成してあります[CLynn]。
(13) Performance Algorithms
(13) パフォーマンスアルゴリズム
HR-CL contains a number of requirements on TCP performance
algorithms; Van Jacobson's slow start and congestion avoidance,
Karn's algorithm, Nagle's algorithm, and SWS prevention at the
sender and receiver. Implementors of new TCPs really need more
guidance than could possibly be included in the HR RFCs. The
working group suggested that an RFC on TCP performance is needed,
to describe each of these issues more deeply and especially to
explain how they fit together.
HR-CLはTCP性能アルゴリズムに関する多くの要件を含んでいます。 送付者と受信機でジェーコブソンの遅れた出発、輻輳回避、Karnのアルゴリズム、ネーグルのアルゴリズム、およびSWS防止をバンに積んでください。新しいTCPsの作成者は本当にHR RFCsに含むことができたより多くの指導を必要とします。 ワーキンググループは、TCP性能のRFCがそれらがどう一緒に合うかを説明するためにそれぞれのこれらの問題について、より深く、そして特に説明するのに必要であることを示しました。
Another issue raised by the HR RFCs is the need for validation (or
rejection) of Van Jacobson's fast retransmit algorithm.
HR RFCsによって提起された別の問題はヴァン・ジェーコブソンの合法化(または、拒絶)の必要性が速くアルゴリズムを再送するということです。
Application-Layer Issues:
応用層問題:
(14) Proposed FTP extensions
(14) 提案されたFTP拡大
A number of minor extensions proposed for FTP should be processed
FTPのために提案された多くの小さい方の拡大が処理されるべきです。
Braden [Page 12] RFC 1127 Perspective on Host Requirements October 1989
ホスト要件1989年10月のブレーデン[12ページ]RFC1127見解
and accepted or rejected. We are aware of the following
proposals:
受け入れられるか拒絶されています。 私たちは以下の提案を意識しています:
(a) Atomic Store Command
(a) 原子保存命令
The FTP specification leaves undefined the disposition of a
partial file created when an FTP session fails during a store
operation. It was suggested that this ambiguity could be
resolved by defining a new store command, Store Atomic (STOA).
The receiver would delete the partial file if the transfer
failed before the final data-complete reply had been sent.
This assumes the use of a transfer mode (e.g., block) in which
end-of-file can be distinguished from TCP connection failure,
of course.
FTP仕様はFTPセッションが店舗運営の間、失敗すると作成された部分的なファイルの気質を未定義の状態でおきます。 新しい保存命令、ストアAtomic(STOA)を定義することによってこのあいまいさを取り除くことができるだろうことが提案されました。 最終的なデータ完全な回答を送る前に転送が失敗するなら、受信機は部分的なファイルを削除するでしょうに。 これがTCP接続の故障とどのファイルの終りを区別できるかで転送モードの使用を仮定する(例えば、ブロック)、もちろん。
(b) NDIR Command
(b) NDIRコマンド
"NDIR would be a directories-only analogue to the NLST command.
Upon receiving an NDIR command an FTP server would return a
list of the subdirectories to the specified directory or file
group; or of the current directory if no argument was sent.
... The existing NLST command allows user FTPs to implement
user-interface niceties such as a "multiple get" command. It
also allows a selective (as opposed to generative) file-naming
user interface: the user can pick the desired file out of a
list instead of typing its name." [Matthews]
「NDIRはNLSTコマンドへのディレクトリだけアナログでしょう。」 NDIRコマンドを受け取ると、FTPサーバは指定されたディレクトリかファイルグループにサブディレクトリのリストを返すでしょう。 または、カレントディレクトリでは、いいえなら議論を送りました。 ... 既存のNLSTコマンドで、ユーザFTPは「倍数は得る」というコマンドなどのユーザーインタフェースの正確さを実装することができます。 また、それは選択している(発生と対照的に)ファイルを命名するユーザーインタフェースを許容します: 「ユーザは名前をタイプすることの代わりにリストから必要なファイルを選ぶことができます。」 [マシューズ]
However, the interface needs to distinguish files from
directories. Up to now, such interfaces have relied on a bug
in many FTP servers, which have included directory names in the
list returned by NLST. As hosts come into conformance with
HR-AS, we need an NDIR command to return directory names.
しかしながら、インタフェースは、ディレクトリとファイルを区別する必要があります。 これまで、そのようなインタフェースは多くのFTPサーバでバグを当てにしました。(サーバはNLSTによって返されたリストにディレクトリ名を含んでいました)。ホストがHR-ASとの順応に入るとき、私たちはディレクトリ名を返すNDIRコマンドを必要とします。
(c) Adaptive Compression
(c) 適応型の圧縮
It has been suggested that a sophisticated adaptive data
compression algorithm, like that provided by the Unix
"compress" command, should be added as an alternative FTP
transfer mode.
高度な適応型のデータ圧縮アルゴリズムがUnix「圧縮」コマンドで提供されたそのように代替のFTP転送モードとして加えられるべきであると示唆されました。
(15) SMTP: Global Mail Addressing
(15)SMTP: グローバルなメールアドレシング
While writing requirements for electronic mail, the working group
was urged to set rules for SMTP and RFC-822 that would be
universal, applicable not only to the Internet environment but
also to the other mail environments that use one or both of these
protocols. The working group chose to ignore this Siren call, and
instead limit the HR RFC to requirements specific to the Internet.
電子メールのための要件を書いている間、ワーキンググループが普遍的なSMTPとRFC-822のために決まりを定めるよう促されました、単にインターネット環境に適切であるのではなく、これらのプロトコルの1か両方を使用する他のメール環境にも適切です。 ワーキンググループは、このSiren呼び出しを無視して、代わりにHR RFCをインターネットに特定の要件に制限するのを選びました。
Braden [Page 13] RFC 1127 Perspective on Host Requirements October 1989
ホスト要件1989年10月のブレーデン[13ページ]RFC1127見解
However, the networking world would certainly benefit from some
global agreements on mail routing. Strong passions are lurking
here.
しかしながら、確かに、ネットワーク世界はメールルーティングのいくつかのグローバルな協定の利益を得るでしょう。 強い情熱はここに潜んでいます。
(16) DNS: Fully Replacing hosts.txt
(16)DNS: 完全である、Replacing hosts.txt
As noted in HR-AS [AS 6.1.3.8], the DNS does not yet incorporate
all the potentially-useful information included in the DDN NIC's
hosts.txt file. The DNS should be expanded to cover the hosts.txt
information. RFC-1101 [RFC-1101] is a step in the right
direction, but more work is needed.
HR-ASで有名である、[AS、6.1、.3、.8、]、DDN NICのhosts.txtファイルにすべての潜在的に有用性のある情報を含んでいて、DNSはまだ盛込んでいません。 DNSは、hosts.txt情報をカバーするために広げられるべきです。 RFC-1101[RFC-1101]は正しい方向にステップですが、より多くの仕事が必要です。
5. SUMMARY
5. 概要
We have summarized the results of the Host Requirements Working Group, and listed a set of issues in Internet host protocols that need future effort.
私たちは、Host Requirements作業部会の結果をまとめて、将来の取り組みを必要とするインターネット・ホストプロトコルの1セットの問題を記載しました。
6. REFERENCES
6. 参照
[RFC-1122] Braden, R., Editor, "Requirements for Internet Hosts -- Communications Layers", RFC 1122, IETF Host Requirements Working Group, October 1989.
[RFC-1122] ブレーデン、R.、エディタ、「インターネットホストのための要件--コミュニケーションは層にする」、RFC1122、IETFホスト要件作業部会、10月1989
[RFC-1123] Braden, R., Editor, "Requirements for Internet Hosts -- Application and Support", RFC 1123, IETF Host Requirements Working Group, October 1989.
[RFC-1123]ブレーデン、R.、エディタ、「インターネットホストのための要件--、アプリケーションとサポート、」、RFC1123、IETFは要件作業部会(1989年10月)を接待します。
[RFC-1009] Braden, R., and J. Postel, "Requirements for Internet Gateways", RFC 1009, USC/Information Sciences Institute, June 1987.
[RFC-1009]ブレーデン、R.とJ.ポステル、「インターネットゲートウェイのための要件」RFC1009、科学が1987年6月に設けるUSC/情報。
[RFC-1101] Mockapetris, P., "DNS Encoding of Network Names and Other Types", RFC 1101, USC/Information Sciences Institute, April 1989.
[RFC-1101] Mockapetris、P.、「ネットワーク名と他のタイプのDNSコード化」、RFC1101、科学が1989年4月に設けるUSC/情報。
[RFC-1063] Mogul, J., C. Kent, C. Partridge, and K. McCloghrie, "IP MTU Discovery Options", RFC-1063, DEC, BBN, & TWG, July 1988.
[RFC-1063] ムガール人とJ.とC.ケント、C.ヤマウズラとK.McCloghrie、「IP MTU発見オプション。」RFC-1063、1988年12月、BBN、およびTWG、7月
[RFC-816] Clark, D., "Fault Isolation and Recovery", RFC-816, MIT, July 1982.
[RFC-816] クラークと、D.と、「欠点分離と回復」、RFC-816、MIT、7月1982
[CLynn] Lynn, C., "Use of TCP Reset to Convey Error Diagnostics", Internal Memo, BBN, December 1988.
[CLynn] リン、C.、「エラー診断を伝えるためにリセットされたTCPの使用」、社内メモ、BBN、1988年12月。
[Lekashman] Message to ietf-hosts mailing list from John Lekashman, 14 September 1988.
ジョンLekashman、1988年9月14日からのietf-ホストメーリングリストへの[Lekashman]メッセージ。
[Matthews] Message to Postel from Jim Matthews, 3 August 1989.
ジム・マシューズ、1989年8月3日からのポステルへの[マシューズ]メッセージ。
Braden [Page 14] RFC 1127 Perspective on Host Requirements October 1989
ホスト要件1989年10月のブレーデン[14ページ]RFC1127見解
APPENDIX I -- ISSUES FOR FUTURE REVISION
付録I--今後の改正のための問題
In order to complete the HR RFCs, it was necessary to defer some technical issues. These issues should be considered by the parties responsible for the first update of the HR RFCs.
HR RFCsを完成するために、いくつかの専門的な問題を延期するのが必要でした。 これらの問題はHR RFCsの最初のアップデートに責任があるパーティーによって考えられるべきです。
The issues pending at the time of publication are listed here, in order by protocol layer.
公表時点で未定の問題はプロトコル層のそばにオーダーにここに記載されています。
General Issue:
一般答弁:
Error Logging
エラー・ロギング
The working group felt that more complete and explicit guidance on
error logging procedures is needed than is presently contained in
Section 1.2.3 (both HR RFCs).
ワーキンググループは、現在セクション1.2.3(両方のHR RFCs)に含まれているよりエラー・ロギング手順におけるより完全で明白な指導が必要であると感じました。
Link Layer Issues:
層の問題をリンクしてください:
- Stolen IP Address
- 盗まれたIPアドレス
How should a host react when it detects through ARP traffic that
some other host has "stolen" its IP address?
ある他のホストがIPアドレスを「盗んだこと」がARPを通してトラフィックを検出するとき、ホストはどのように反応するべきですか?
IP Layer Issues:
IP層の問題:
- "Raw Mode" Interface
- 「生のモード」インタフェース
HR-CL could define an optional "raw mode" interface from the
application layer to IP.
HR-CLは応用層からIPまで任意の「生のモード」インタフェースを定義できました。
- Rational Fragmentation
- 合理的な断片化
When a host performs intentional fragmentation, it should make the
first fragment as large as possible (this same requirement should
be placed on gateways).
ホストが意図的な断片化を実行するとき、それで、最初の断片はできるだけ大きくなるべきです(この同じ要件はゲートウェイに置かれるべきです)。
- Interaction of Multiple Options
- 複数のオプションの相互作用
HR-CL does not give specific rules for the interactions of
multiple options in the same IP header; this issue was generally
deferred to a revision of the Gateway Requirements RFC. However,
this issue might be revisited for hosts.
HR-CLは同じIPヘッダーでの複数のオプションの相互作用のために特定の規則を与えません。 一般に、この問題はゲートウェイRequirements RFCの改正に延期されました。 しかしながら、この問題はホストのために再訪するかもしれません。
- ICMP Error for Source-Routed Packet
- ソースによって発送されたパケットのためのICMP誤り
It was suggested that when a source-routed packet arrives with an
error, any ICMP error message should be sent with the
ソースによって発送されたパケットが誤りと共に到着するとき、どんなICMPエラーメッセージと共にも発信するべきであると示唆されました。
Braden [Page 15] RFC 1127 Perspective on Host Requirements October 1989
ホスト要件1989年10月のブレーデン[15ページ]RFC1127見解
corresponding return route. This assumes that the ICMP error
message is more likely to be delivered successfully with the
source route than without it.
対応する戻り経路。 これは、ICMPエラーメッセージがそれより送信元経路で首尾よく提供されそうであると仮定します。
- "Strong" IP Options and ICMP Types
- 「強い」IPオプションとICMPタイプ
The HR RFCs takes the general approach that a host should ignore
whatever it does not understand, so that possible future
extensions -- e.g., new IP options or new ICMP message types --
will cause minimum problems for existing hosts. The result of
this approach is that when new facilities are used with old hosts,
a "black hole" can result. Several people have suggested that
this is not always what is wanted; it may sometimes be more useful
to obtain an ICMP error message from the old host. To quote
Jeremey Siegel:
何を理解していなくても、HR RFCsはホストが無視するべきである一般的方法を取ります、可能な今後の拡大(例えば、新しいIPオプションか新しいICMPメッセージタイプ)は既存のホストのために最小の問題を引き起こすでしょう。 このアプローチの結果は新しい設備が年取ったホストと共に使用されるとき、「ブラックホール」が結果として生じることができるということです。 数人は、これがいつも欲しいものであるというわけではないと示唆しました。 年取ったホストからICMPエラーメッセージを得るのは時々より役に立つかもしれません。 Jeremeyシーゲルを引用するために:
"The basic premise is that if an option is to have any real
meaning at all within an '[upward] compatible' environment, it
must be known whether or not the option actually *carries* its
meaning. An absurd analogy might be programming languages: I
could make a compiler which simply ignored unknown sorts of
statements, thereby allowing for future expansion of the
language.
「オプションが'[上向き]のコンパチブル'環境の中に何か全く真の意義を持つことであるなら根本的な前提がそれである、それを知っていなければならない、オプション、実際に*桁上げ*を意味する、」 とんでもない類推はプログラミング言語であるかもしれません: 私は単に未知の種類の声明を無視した、その結果、言語の今後の拡張を考慮したコンパイラを作ることができました。
Right now, there are four "classes" of options; only two are
defined. Take one of the other classes, and define it such
that any options in that class, if unrecognized, cause an ICMP
error message. Thus anyone who wants to propose a "strong"
option (one which requires full participation by all systems
involved to operate correctly) can assign it to that class.
Options in the current classes may still be passed through if
they are unknown; only "weak" options will be assigned to these
classes in the future."
たった今、4「クラス」のオプションがあります。 2だけが定義されます。 他のクラスの1つを取ってください、そして、認識されていないならそのクラスにおけるどんなオプションもICMPエラーメッセージを引き起こすように、それを定義してください。 したがって、「強い」オプション(正しく作動するためにかかわるすべてのシステムで全面参加を必要とするもの)を提案したがっているだれでもそのクラスにそれを配属できます。 それらが未知であるなら、現在のクラスにおけるオプションはまだ通り抜けているかもしれません。 「「弱い」オプションだけが将来、これらのクラスに配属されるでしょう。」
- Network Mask
- ネットワークマスク
As explained in HR-CL [CL 3.1.2.3], we believe that a possible
future transition for the interpretation of IP addresses may be
eased if hosts always treat an IP address as an indivisible 32-
bit number. However, there are various circumstances where a host
has to distinguish its own network number. Charlie Lynn has
suggested that indivisibility can be retained if a host is
configured with both an address mask (indicating subnetting) and a
network mask (with network but not subnet bits).
HR-CLで説明される、[CL、3.1、.2、.3、]、私たちは、分割できない32が数に噛み付いたのでホストがいつもIPアドレスを扱うならIPアドレスの解釈のための可能な将来の変遷が緩和されるかもしれないと信じています。 しかしながら、様々な事情がホストがそれ自身のネットワーク・ナンバーを区別しなければならないところにあります。 チャーリーリンは、ホストがアドレスマスク(サブネッティングを示す)とネットワークマスク(サブネットビットではなく、ネットワークがある)の両方によって構成されるなら不可分性を保有できるのを示しました。
- WhoAmI Query
- WhoAmI質問
The following requirement is needed: for a multihomed host, a
以下の要件が必要です: 「マルチ-家へ帰」っているホスト、aのために
Braden [Page 16] RFC 1127 Perspective on Host Requirements October 1989
ホスト要件1989年10月のブレーデン[16ページ]RFC1127見解
UDP-based application should (must?) be able to query the
communication layers to obtain a list of all local IP addresses
for the host.
UDPベースのアプリケーション、(must?)は、すべてのローカルアイピーアドレスのリストをホストに得るためにコミュニケーション層について質問するはずであることができますか?
- New Destination Unreachable codes
- 新しいDestination Unreachableコード
For each of the new ICMP Destination Unreachable codes defined in
HR-CL [CL 3.2.2.1], it should be documented whether the error is
"soft" or "hard".
HR-CLで定義されたそれぞれの新しいICMP Destination Unreachableコード、[CL、3.2、.2、.1、]、誤りが「柔らかい」か「困難であること」にかかわらずそれは記録されるべきです。
- ICMP Error Schizophrenia
- ICMP誤り精神分裂症
Section 3.3.8 of HR-CL requires a host to send ICMP error
messages, yet in nearly all individual cases the specific
requirements say that errors are to be silently ignored. The
working group recognized this contradiction but was unwilling to
resolve it.
.8セクション3.3HR-CLが、ホストがエラーメッセージをICMPに送るのを必要とします、しかし、ほとんどすべての個々の場合では、決められた一定の要求は誤りが静かに無視されることであると言います。 ワーキンググループは、この矛盾を認識しましたが、それを決議したがっていませんでした。
At every choice point, the working group opted towards a
requirement that would avoid broadcast storms. For example, (1)
ICMP errors cannot be sent for broadcasts, and also (2) individual
errors are to be silently ignored. This is redundant; either
provision (1) or (2) alone, if followed, should eliminate
broadcast storms. The general area of responses to errors and
broadcast storms could be reassessed and the individual decisions
reviewed.
(2) (1) 例えば、あらゆる特選しているポイント(ブロードキャスト・ストームを避ける要件に向かって選ばれたワーキンググループ)では、放送のためにICMP誤りを送ることができるというわけではありません、そして、また、個々の誤りは静かに無視することです。 これは余分です。 続かれているなら、支給(1)か(2)のどちらかだけがブロードキャスト・ストームを排除するべきです。誤りとブロードキャスト・ストームへの応答の一般的な領域を再評価できました、そして、個々の決定は論評しました。
Transport-Layer Requirements:
トランスポート層要件:
- Delayed ACK Definition
- 遅れたACK定義
A more precise and complete definition of the conditions for
delaying a TCP ACK segment may be desirable; see Section 4.2.3.2
of HR-CL.
TCP ACKセグメントを遅らせるための状態の、より正確で完全な定義は望ましいかもしれません。 セクション4.2を見てください。.3 .2HR-CL。
Telnet Requirements:
telnet要件:
- Flushing Output
- 出力を洗い流します。
The DISCUSSION in Section 3.2.4 of HR-AS concerns three possible
ways for a User Telnet to flush output. It would be helpful for
users and implementers if one of these could be recommended over
the others; however, when the working group discussed the matter,
there seemed to be compelling arguments for each choice. This
issue needs more study.
.4セクション3.2HR-ASのDISCUSSIONはUser Telnetが出力を洗い流す3つの可能な方法に関係があります。 他のものの上でこれらの1つを推薦できれば、ユーザとimplementersにおいて、助かるでしょうに。 しかしながら、ワーキンググループがその件について議論したとき、各選択のためのいやとは言いにくい話はあるように思えました。 この問題は、より多くの研究を必要とします。
Braden [Page 17] RFC 1127 Perspective on Host Requirements October 1989
ホスト要件1989年10月のブレーデン[17ページ]RFC1127見解
- Telnet LineMode Option
- telnet LineModeオプション
This important new option is still experimental, but when it
becomes a standard, implementation should become recommended or
required.
この重要な新しいオプションはまだ実験的ですが、規格になると、実装はお勧めか必要になるべきです。
FTP Requirements:
FTP要件:
- Reply Codes
- 回答コード
A number of problems have been raised with FTP reply codes.
多くの問題がFTP回答コードで提起されました。
(a) Access Control Failures
(a) アクセス制御失敗
Note that a 550 message is used to indicate access control
problems for a read-type operation (e.g., RETR, RNFR), while a 553
message is used for the same purpose for a write-type operation
(e.g., STOR, STOU, RNTO).
550メッセージがタイプを読んでいる操作(例えば、RETR、RNFR)のためにアクセス制御の問題を示すのに使用されることに注意してください、553メッセージはタイプに書いている操作(例えば、STOR、STOU、RNTO)のための同じ目的に使用されますが。
LIST, NLST, and STAT may fail with a 550 reply due to an access
control violation.
アクセス制御違反による550回答に応じて、LIST、NLST、およびSTATは失敗するかもしれません。
MKD should fail with a 553 reply if a directory already exists
with the same name.
ディレクトリが同じ名前で既に存在しているなら、553回答に応じて、MKDは失敗するはずです。
(b) Directory Operations (RFC-959 Appendix II)
(b) ディレクトリ操作(RFC-959付録II)
An RMD may result in a 450 reply if the directory is busy.
ディレクトリが忙しいなら、RMDは450回答をもたらすかもしれません。
Many of the reply codes shown in the text of Appendix II are
wrong. A positive completion for CWD should be 250. The 521 code
shown for MKD should be 553 (see above), while the 431 shown for
CWD should be a 550.
Appendix IIのテキストに示された回答コードの多くが間違っています。 CWDに、積極的な完成は250であるべきです。 MKDのために示された521コードは553であるべきであり(上を見る)、431である間、CWDのために示されているのは、550であるべきです。
(c) HELP and SITE Commands
(c)支援とサイトコマンド
The positive completion reply to a HELP command should be code
214.
HELPコマンドに関する積極的な完成回答はコード214であるべきである。
HELP or SITE with an invalid argument should return a 504 reply.
根拠のない議論があるヘルプかSITEが504回答を返すはずです。
- Bidirectional FTP
- 双方向のFTP
The FTP specification allows an implementation in which data
transfer takes place in both directions simultaneously, although
few if any implementations support this. Perhaps HR-AS should
take a stand for or against this.
FTP仕様はデータ転送が同時に両方の方向に行われる実装を許容します、わずかしかどんな実装であるならもこれをサポートしませんが。 恐らく、HR-ASはこれを支持して、または、これに対して明確な態度を打ち出すはずです。
Braden [Page 18] RFC 1127 Perspective on Host Requirements October 1989
ホスト要件1989年10月のブレーデン[18ページ]RFC1127見解
SMTP Requirements:
SMTP要件:
- Offline SEND
- オフラインで、発信してください。
Some on the working group felt that the SMTP SEND command,
intended to display a message immediately on the recipient's
terminal, should produce an error message if delivery must be
deferred.
ワーキンググループの或るものは、配送を延期しなければならないならすぐ受取人の端末でメッセージを表示することを意図するSMTP SENDコマンドがエラーメッセージを作り出すべきであると感じました。
- Header-like Fields
- ヘッダーのような分野
John Klensin proposed:
ジョンKlensinは提案しました:
"Header-like fields whose keywords do not conform to RFC822 are
strongly discouraged; gateways SHOULD filter them out or place
them into the message body. If, however, they are not removed,
Internet hosts not acting as gateways SHOULD NOT utilize or
inspect them. Hence address-like subfields of those fields SHOULD
NOT be altered by the gateway."
「キーワードがRFC822に従わないヘッダーのような分野は強くがっかりしています」。 ゲートウェイSHOULDはそれらを無視するか、またはメッセージ本体にそれらを置きます。 しかしながら、それらが取り除かれないなら、ゲートウェイSHOULD NOTとして務めていないインターネット・ホストが、それらを利用するか、または点検します。 「それらのしたがって、アドレスのような部分体がSHOULD NOTをさばく、ゲートウェイによって変更されてください、」
- Syntax of Received: Line
- 構文、受け取られている: 線
The precise syntax of a revised Received: line (see Section 5.2.8
of HR-AS) could be given. An unresolved question concerned the
use of "localhost" rather than a fully-qualified domain name in
the FROM field of a Received: line. Finally, new syntax was
proposed for the Message Id field.
改訂されたReceivedの正確な構文: 系列(.8セクション5.2HR-ASを見る)を与えることができました。 未解決の問題はReceivedのFROM分野で完全修飾ドメイン名よりむしろ"localhost"の使用に関係がありました: 立ち並んでください。 最終的に、新しい構文はMessage Id分野に提案されました。
Appendix II -- Gateway Issues
付録II--ゲートウェイ問題
The working group identified a set of issues that should be
considered when the Gateway Requirements RFC [RFC-1009] ("GR RFC") is
revised.
ワーキンググループは1セットのゲートウェイRequirements RFC[RFC-1009]("GR RFC")が改訂されていると考えられるべき問題を特定しました。
- All-Subnets Broadcast
- オールサブネット放送
This facility is not currently widely implemented, and HR-CL warns
users of this fact. The GR RFC should take a stand on whether or
not gateways ought to implement the necessary routing.
この施設は現在広く実装されません、そして、HR-CLはこの事実についてユーザに警告します。 ゲートウェイが必要なルーティングを実装するべきであるかどうかに関してGR RFCは明確な態度を打ち出すはずです。
- Rational Fragmentation
- 合理的な断片化
When a gateway performs intentional fragmentation, it should make
the first fragment as large as possible.
ゲートウェイが意図的な断片化を実行するとき、それで、最初の断片はできるだけ大きくなるべきです。
- Illegal Source Address
- 不法なソースアドレス
It has been suggested that a gateway should not forward a packet
ゲートウェイがパケットを進めるはずがないと示唆されました。
Braden [Page 19] RFC 1127 Perspective on Host Requirements October 1989
ホスト要件1989年10月のブレーデン[19ページ]RFC1127見解
containing an illegal IP source address, e.g., zero.
不法なIPソースアドレス、例えばゼロを含んでいます。
- Option Processing
- オプション処理
Specific rules should be given for the order of processing
multiple options in the same IP header. Two approaches have been
used: to process options in the order presented, or to parse them
all and then process them in some "canonical" order.
同じIPヘッダーで複数のオプションを処理する注文のために特定の規則を与えるべきです。 2つのアプローチが使用されました: 何らかの「正準な」オーダーで提示されたオーダーにおけるオプションを処理するか、それらを皆、分析して、または次に、それらを処理するために。
The legality should also be defined for using broadcast or
multicast addresses in IP options that include IP addresses.
また、合法は、IPアドレスを含んでいるIPオプションに放送かマルチキャストアドレスを使用するために定義されるべきです。
Security Considerations
セキュリティ問題
A future revision of the Host Requirements RFCs should incorporate a more complete discussion of security issues at all layers.
Host Requirements RFCsの今後の改正はすべての層で安全保障問題の、より完全な議論を取り入れるべきです。
Author's Address
作者のアドレス
Robert Braden USC/Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292-6695
ロバートブレーデンUSC/Information Sciences Institute4676海軍本部Wayマリナデルレイ、カリフォルニア90292-6695
Phone: (213) 822 1511
以下に電話をしてください。 (213) 822 1511
EMail: Braden@ISI.EDU
メール: Braden@ISI.EDU
Braden [Page 20]
ブレーデン[20ページ]
一覧
スポンサーリンク
