RFC2075 日本語訳

Network Working Group                                       C. Partridge
Request for Comments: 2075                                           BBN
Category: Experimental                                      January 1997

コメントを求めるワーキンググループC.ヤマウズラ要求をネットワークでつないでください: 2075年のBBNカテゴリ: 実験的な1997年1月

                          IP Echo Host Service

IPエコーホストサービス

Status of this Memo

このMemoの状態

   This memo defines an Experimental Protocol for the Internet
   community.  This memo does not specify an Internet standard of any
   kind.  Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.

このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 このメモはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。

Abstract

要約

   This memo describes how to implement an IP echo host.  IP echo hosts
   send back IP datagrams after exchanging the source and destination IP
   addresses.  The effect is that datagrams sent to the echo host are
   sent back to the source, as if they originated at the echo host.

このメモはIPエコーホストを実装する方法を説明します。 IPが演説するソースと目的地を交換した後に、IPエコーホストはIPデータグラムを返送します。 効果はエコーホストに送られたデータグラムがソースに送り返されるということです、まるでエコーホストで起因するかのように。

Introduction

序論

   An IP echo host returns IP datagrams to their original source host,
   with the IP source and destination addresses reversed, so that the
   returning datagram appears to be coming from the echo host to the
   original source.  IP echo hosts are tremendously useful for debugging
   applications and protocols.  They allow researchers to create looped
   back conversations across the Internet, exposing their traffic to all
   the vagaries of Internet behavior (congestion, cross traffic,
   variable round-trip times and the like) without having to distribute
   prototype software to a large number of test machines.

IPエコーホストは彼らの一次資料ホストにIPデータグラムを返します、IPソースと送付先アドレスが逆にされている状態で、戻っているデータグラムがエコーホストから一次資料に来るように見えるように。 IPエコーホストはものすごくデバッグアプリケーションとプロトコルの役に立ちます。 彼らは研究者にインターネットの向こう側に輪にされた逆会話を作成させます、多くの材料試験機にプロトタイプソフトウェアを分配する必要はなくてインターネットの振舞い(混雑、交差交通、可変往復の回、および同様のもの)のすべての気まぐれにそれらのトラフィックを暴露して。

   IP echo hosts were heavily used on the Internet in the late 1970s and
   early 1980s to debug various Internet transport and application
   protocols.  But, for reasons unclear, at the current date there are
   no echo hosts on the Internet and few people are even aware of the
   concept.  The goal of this memo is to document the concept in the
   hopes it will be revived.

IPエコーホストは、1970年代後半と1980年代前半に様々なインターネット輸送とアプリケーションプロトコルをデバッグするのにインターネットで大いに使用されました。 しかし、現在の期日に不明瞭な理由で、エコーホストは全くインターネットにいません、そして、わずかな人々が概念を意識してさえいます。 このメモの目標はそれが蘇るという望みに概念を記録することです。

Implementation Details

実装の詳細

   While the basic idea of a echo host is simple, there are a few
   implementation details that require attention.  This section
   describes those implementation details.  The presentation works from
   the simplest to most difficult issues.

エコーホストの基本的な考え方は簡単ですが、注意を必要とするいくつかの実装の詳細があります。 このセクションはそれらの実装の詳細について説明します。 プレゼンテーションは最も簡単であるのからほとんどの難しい問題まで働いています。

Partridge                     Experimental                      [Page 1]

RFC 2075                  IP Echo Host Service              January 1997

[1ページ]RFC2075IPエコーホストサービス1997年1月の実験用のヤマウズラ

   The most straightforward situation is when an echo host receives an
   IP datagram with no options and whose protocol field has a value
   other than 1 (ICMP).  In this case, the echo host modifies the header
   by exchanging the source and destination addresses, decrements the
   TTL by one and updates the IP header checksum.  The host then
   transmits the updated IP datagram back to the original source of the
   datagram.

最も簡単な状況は1(ICMP)以外のエコーホストがいつオプションなしでIPデータグラムを受け取るか、そして、だれのプロトコル分野に値があるかということです。 この場合、エコーホストは、ソースと送付先アドレスを交換することによってヘッダーを変更して、TTLを1つ減少させて、IPヘッダーチェックサムをアップデートします。 そして、ホストはアップデートされたIPデータグラムをデータグラムの一次資料に送って戻します。

      NOTE: If the TTL is zero or less after decrementing, the datagram
      MUST not be echoed.  In general, an echo host is required to do
      all the various sanity checks that a router or host would do to an
      IP datagram before accepting the datagram for echoing (see STD 3,
      RFC 1122, and RFC 1812).

以下に注意してください。 TTLが減少の後のゼロか以下であるなら、データグラムを反響してはいけません。 一般に、エコーホストが、反響するためのデータグラムを受け入れる前にルータかホストがIPデータグラムにするすべての様々な健全度チェックをするのに必要です(STD3、RFC1122、およびRFC1812を見てください)。

      The TTL MUST be decremented for security reasons noted below.
      Observe, however, that the effect is that hosts using an echo path
      through an echo host SHOULD set their TTL to twice the normal
      value to be sure of achieving connectivity over the echo path.

TTL MUST、以下に述べられたセキュリティ理由で、減少してください。 しかしながら、効果がエコーホストSHOULDを通してエコー経路を使用しているホストがエコー経路の上で接続性を達成するのが確かになるように正常値の2倍に彼らのTTLを設定するということであることを観測してください。

   If an arriving IP datagram has options, the echo host's
   responsibilities are more complex.  In general, the IP source and
   destination are always exchanged and TTL and checksum updated, but in
   certain situations, other special actions may have to take place.

到着しているIPデータグラムにオプションがあるなら、エコーホストの責任は、より複雑です。 しかし、ある状況でTTLとチェックサムをアップデートして、一般に、いつもIPソースと目的地を交換して、他の特別な動きは行われなければならないかもしれません。

   If the datagram contains an incomplete source route option (i.e. the
   echo host is not the final destination), the datagram MUST be
   discarded.  If the datagram contains a complete source route option,
   the source route option MUST be reversed, and the datagram (with
   source and destination IP addresses exchanged and updated TTL) MUST
   be sent back along the reverse source route.

データグラムが不完全な送信元経路オプションを含んでいるなら(すなわち、エコーホストは最終的な目的地ではありません)、データグラムを捨てなければなりません。 データグラムが完全な送信元経路オプションを含んでいるなら、送信元経路オプションを逆にしなければなりません、そして、逆の送信元経路に沿ってデータグラム(アドレスは、ソースと目的地IPと共に、TTLを交換して、アップデートした)を返送しなければなりません。

   More generally, the goal with any option is to update the option such
   that when the echoed packet is received at the original source, the
   option fields will contain data which makes sense for a datagram
   originating at the echo host.

より一般に、どんなオプションがある目標も一次資料に反響しているパケットを受け取るとき、オプション・フィールドがエコーホストで起因するデータグラムのために理解できるデータを含むようにオプションをアップデートすることです。

   There is one option for which it is unclear what the correct action.
   The timestamp option is sometimes used for round-trip time
   estimation.  If the option is reset at the echo host, then a history
   of roughly half of the trip delay will be lost.  But if the option is
   not reset, then the timestamp option will appear inconsistent with
   the source and destination addresses of the datagram.  To try to
   balance these two issues, the following rules are suggested:

それが不明瞭である1つのオプションがある、何、正しい動作。 タイムスタンプオプションは往復の時間見積りに時々使用されます。 オプションがエコーホストにリセットされると、およそ旅行遅れの半分の歴史は失われるでしょう。 しかし、オプションがリセットされないと、タイムスタンプオプションはデータグラムのソースと送付先アドレスに矛盾しているように見えるでしょう。 これらの2冊のバランスをとろうとするために、以下の規則は示されます:

      1. If the first entry in the timestamp option contains the IP
      address of the source host, the entry SHOULD be rewritten to
      contain the IP address of the echo host, and the timestamp option
      pointer SHOULD be truncated so that this timestamp is the only one

1. 中のタイムスタンプオプションが含むIPが扱う送信元ホスト、エントリーSHOULDの初記入による書き直されて、エコーホストのIPアドレス、およびタイムスタンプオプション指針SHOULDを含むように、端が欠けてください。そうすれば、このタイムスタンプが唯一無二であるということです。

Partridge                     Experimental                      [Page 2]

RFC 2075                  IP Echo Host Service              January 1997

[2ページ]RFC2075IPエコーホストサービス1997年1月の実験用のヤマウズラ

      in the list.  (This rewrite makes the option appear consistent
      with the new source and destination IP addresses, and retains the
      source timestamp, while losing information about the path to the
      echo host).

リストで。 (この書き直しは、オプションを新しいソースと送付先IPアドレスと一致しているように見えさせて、エコーホストに経路の情報を失っている間、ソースタイムスタンプを保有します。)

      2. If the first entry in the timestamp option does not contain the
      IP address of the source host, the entry SHOULD be echoed back
      unchanged. The echo host SHOULD NOT appear in the timestamp
      option.  (This approach retains the entire history of the path,
      though observe that on a symmetric route, it means every router
      may appear twice in the path).

2. 反響している背中が変わりがなかったならタイムスタンプオプションにおける初記入が送信元ホスト、エントリーSHOULDのIPアドレスを含んでいないなら。 エコーホストSHOULD NOTはタイムスタンプオプションに現れます。 (このアプローチが経路の全体の歴史を保有する、もっとも、左右対称のルートの上では、それが、あらゆるルータが経路に二度現れるかもしれないことを意味するのを観測してください、)

   Finally, if the IP datagram contains an ICMP packet (i.e. the IP
   protocol field value is 1), the datagram SHOULD be discarded.  The
   reason for this rule is that the most likely reason for receiving an
   ICMP datagram is that an echoed datagram has encountered a problem at
   some router in the path and the router has sent back an ICMP
   datagram.  Echoing the ICMP datagram back to the router may confuse
   the router and thus SHOULD be avoided.  (This rule simply follows the
   Internet maxim of being conservative in what we send).

IPデータグラムはICMPパケットを含んでいます(すなわち、IPプロトコル分野価値は1です)、データグラムSHOULD。最終的である、捨てられます。 この規則の理由はICMPデータグラムを受ける最も多くのありそうな理由が反響しているデータグラムが経路の何らかのルータで問題に行きあたって、ルータがICMPデータグラムを返送したということであるということです。 ICMPデータグラムをルータにecho backであると、ルータとその結果SHOULDは混乱するかもしれません。避けられます。 (この規則は単に私たちが送るもので保守的であることのインターネット格言に従います。)

   However, in some cases the ICMP datagram will have useful information
   for the source host which it would be desirable to echo.  A
   sophisticated echo host MAY choose to echo ICMP datagrams according
   to the following rules:

しかしながら、いくつかの場合、ICMPデータグラムには、送信元ホストへの反響するのが望ましい役に立つ情報があるでしょう。 洗練されたエコーホストは、以下の規則に従ってICMPデータグラムを反響するのを選ぶかもしれません:

      1. Any ICMP datagram in which the destination address in the
      encapsulated IP header (the header within the ICMP datagram)
      matches the source address of the ICMP datagram MAY be safely
      echoed.

1. カプセル化されたIPヘッダー(ICMPデータグラムの中のヘッダー)の送付先アドレスがICMPデータグラムのソースアドレスに合っているどんなICMPデータグラムも安全に反響されるかもしれません。

      2. ICMP Source Quench and ICMP Destination Unreachable with a code
      of 4 (fragmentation needed and DF set) MAY be sent to the
      *destination* of the encapsulated IP datagram if the source IP
      address of the encapsulated IP datagram is that of the echo host.
      When the ICMP message is sent on, it SHOULD be rewritten as an
      ICMP message from the echo host to the source.

2. カプセル化されたIPデータグラムのソースIPアドレスがエコーホストのものであるなら4(必要である断片化とDFはセットした)のコードがあるICMP Source QuenchとICMP Destination Unreachableをカプセル化されたIPデータグラムの*目的地*に送るかもしれません。 いつ、ICMPメッセージがあるかは転送されて、それはSHOULDです。ICMPメッセージとして、エコーホストからソースまで書き直されてください。

      3. All other ICMP messages MUST be discarded.

3. 他のすべてのICMPメッセージを捨てなければなりません。

   These rules were chosen to try to ensure that end-to-end ICMP
   messages are passed through, as are messages from routers which are
   fairly safe and useful (or necessary) to the end system, but that
   potentially dangerous messages such as Redirects are suppressed.
   (The ICMP Destination Unreachable with code 4 is required for MTU
   discovery under RFC-1191).

これらの規則は終わりから終わりへのICMPメッセージが通り抜けるのを保証しようとするために選ばれました、かなり安全で役に立って(必要)であるルータからエンドシステムまでのメッセージのように、しかし、そんなに潜在的に、Redirectsなどの危険なメッセージは削除されます。 (コード4があるICMP Destination UnreachableがRFC-1191の下のMTU発見に必要です。)

Partridge                     Experimental                      [Page 3]

RFC 2075                  IP Echo Host Service              January 1997

[3ページ]RFC2075IPエコーホストサービス1997年1月の実験用のヤマウズラ

Security Considerations

セキュリティ問題

   Echo hosts pose a number of security concerns related to address
   spoofing.

エコーホストはアドレススプーフィングに関連する多くの安全上の配慮を引き起こします。

   First, echo hosts provide obvious ways to extend attacks that make
   use of address spoofing.  A malevolent host can write an third
   party's IP address as the source address of a datagram sent to an
   echo host and thus cause the echo host to send a datagram to the
   third party.  In general, this trick does not create a new security
   hole (the malevolent host could just as well have sent the datagram
   with a forged source address straight to the third party host).  But
   there are some new twists to the problem.

まず最初に、エコーホストはアドレススプーフィングを利用する攻撃を広げる当たり前の方法を提供します。 エコーホストがデータグラムを第三者に送りにデータグラムのソースアドレスでエコーホストとその結果、原因に行ったので、意地の悪いホストは第三者のIPアドレスを書くことができます。 一般に、このトリックは新しいセキュリティーホールを作成しません(また、ちょうど意地の悪いホストは第三者ホストへの偽造ソースアドレスがまっすぐのデータグラムを送ったかもしれません)。 しかし、問題へのいくつかの新しいねじれがあります。

   One exception is if the echo host is a host inside a firewall that
   accepts datagrams from hosts outside the firewall.  In that case, a
   malevolent host outside the firewall may be able to use the echo host
   to make its packets appear to originate from inside the firewall
   (from the echo host).  In general, a good firewall will catch these
   cases (the source address of the datagrams sent to the echo host will
   be for a host inside the firewall and testing for interior source
   addresses on datagrams arriving at an exterior interface is a
   standard firewall filter) but since the primary purpose of echo hosts
   is for wide scale Internet testing, there seems no reason to invite
   danger.  So we recommend that echo hosts SHOULD NOT be placed inside
   firewalls.

1つの例外はエコーホストがホストからデータグラムを受け入れるファイアウォールの中のホストであるかどうかというファイアウォールの外のことです。 その場合、ファイアウォールの外の意地の悪いホストは、パケットをファイアウォール(エコーホストからの)の中から起因するように見えさせるのにエコーホストを使用できるかもしれません。 一般に、良いファイアウォールはこれらのケースを捕らえるでしょうが(ファイアウォールの中にエコーホストに送られたデータグラムのソースアドレスがホストのためにあるでしょう、そして、内部のソースアドレスがないかどうか外のインタフェースに到着しながらデータグラムの上にテストするのは、標準のファイアウォールフィルタです)、エコーホストのプライマリ目的が広いスケールインターネットテストのためのものであるので、危険を招待する理由は全く見えません。 それで、私たちは、エコーホストSHOULD NOTがファイアウォールの中に置かれることを勧めます。

   Second, address spoofing can be used to cause flooding of the
   network.  In this case, a malevolent host sends a datagram to an echo
   host with the source address of another echo host.  This trick will
   cause datagrams to circulate between the two echo hosts.  The
   requirement that the echo host decrement the TTL by one ensures that
   each datagram will eventually die, but a sufficiently malevolent host
   sending a large number of datagrams with high TTLs to an echo host
   can cause considerable disruption.  There are a number of possible
   ways to repair this problem (such as requiring sources to
   authenticate themselves before sending datagrams to be echoed).  A
   simple protection is simply to limit the number of packets echoed
   back to any one source per second.  For instance, one might limit a
   source to a packet rate equal to 10% of the interface bandwidth (for
   a 10 Mb/s Ethernet this would be about 75 maximum sized packets per
   second).

2番目に、ネットワークの氾濫を引き起こすのにアドレススプーフィングを使用できます。 この場合、意地の悪いホストは別のエコーホストのソースアドレスをもっているエコーホストにデータグラムを送ります。 このトリックで、データグラムは2人のエコーホストの間を循環するでしょう。 エコーホストがTTLを1つ減少させるという要件は、各データグラムが結局死ぬのを確実にしますが、高いTTLsがある多くのデータグラムをエコーホストに送る十分意地の悪いホストはかなりの分裂を引き起こす場合があります。 この問題(反響されるようにデータグラムを送る前にソースが自分たちを認証するのが必要であることなどの)を修理する多くの可能な方法があります。 簡単な保護は単にecho backであったパケットの数をどんな1秒あたりのソースにも制限することです。 例えば、人はソースをインタフェース帯域幅の10%と等しいパケットレートに制限するかもしれません(10Mb/sのイーサネットのために、これは1秒あたりおよそ75の最大の大きさで分けられたパケットでしょう)。

   One variation of this attack is to generate e-mail addressed to the
   echo host (e.g., user@echo.xxx.com).  This e-mail will loop over the
   network a number of times until the SMTP server determines the
   message has too many Received-From: lines.

この攻撃の1回の変化はエコーホスト(例えば、 user@echo.xxx.com )に扱われたメールを作ることです。 SMTPサーバーが、メッセージにはあまりに多くのReceived-From:があることを決定するまで、このメールはネットワークの上で幾度か輪にされるでしょう。 系列。

Partridge                     Experimental                      [Page 4]

RFC 2075                  IP Echo Host Service              January 1997

[4ページ]RFC2075IPエコーホストサービス1997年1月の実験用のヤマウズラ

   A third variation of the flooding trick is to place a multicast or
   broadcast address as the source of the IP datagram sent to an echo
   server.  Since this results in an illegal arriving IP datagram, the
   echo server MUST discard the datagram.  (This warning serves as a
   reminder that echo servers MUST do the standard checks for an illegal
   datagram before echoing).

氾濫トリックの3番目の変化はIPデータグラムの源がエコー・サーバーに発信したのでマルチキャストか放送演説を置くことです。これが不法な到着しているIPデータグラムをもたらすので、エコー・サーバーは、データグラムを捨てなければなりません。 (エコー・サーバーが規格をしなければならないということを思い出させるものが反響する前に不法なデータグラムがないかどうかチェックするようにこの警告は役立ちます。)

Implementation Note

実装注意

   Echo hosts are often implemented as virtual interfaces on an existing
   host or router.  One can think of the echo host's IP address as a
   second IP address for the host, with the semantics that all datagrams
   sent to that address get echoed.  Observe that when an echo host is
   supported as a module within a larger host implementation, an easy
   implementation mistake to make is to accidentally put the non-echo
   address of a host into an echoed packet.  For a variety of reasons
   (including security and correct operation of echo paths) implementors
   MUST ensure this NEVER happens.

エコーホストは仮想インターフェースとして既存のホストかルータでしばしば実装されます。 人は、意味論をもっているホストのための2番目のIPアドレスとしてそのアドレスに送られたすべてのデータグラムが反響されるとエコーホストのIPアドレスを考えることができます。 しやすい実装誤りがエコーホストがモジュールとして、より大きいホスト導入の中でサポートされるとき、偶然ホストの非エコーアドレスを反響しているパケットに置くことであることを観測してください。 さまざまな理由(エコー経路のセキュリティと正しい操作を含んでいる)で、作成者は、これが決して起こらないのを保証しなければなりません。

Acknowledgements

承認

   This memo was stimulated by a conversation with Jon Crowcroft in
   which we both lamented the demise of some beloved IP echo hosts
   (e.g., goonhilly-echo.arpa).  It has been considerably improved by
   comments from various members of the End2End-Interest mailing list,
   including Bob Braden, Mark Handley, Christian Huitema, Dave Mills,
   Tim Salo, Vern Schryver, Lansing Sloan, and Rich Stevens.

このメモは私たち二人が何人かの最愛のIPエコーホスト(例えば、goonhilly-echo.arpa)の終焉を悲しんだジョン・クロウクロフトとの会話で刺激されました。 それはEnd2End-関心メーリングリストの様々なメンバーからのコメントでかなり改良されました、ボブ・ブレーデン、マーク・ハンドレー、クリスチャンのHuitema、デーヴ・ミルズ、ティム・サロ、バーンSchryver、ランシング・スローン、およびリッシュ・スティーブンスを含んでいて。

   The author is emphatically not the inventor of echo hosts.  Enquiries
   to the usual suspects suggest that echo hosts were created by persons
   unknown (probably at BBN) very early in the development of IP.  I'd
   like to thank those persons who created echo hosts and apologize for
   any errors in describing their invention.

作者は強調してエコーホストの発明者ではありません。 容疑者としていつも名前が挙がる人への調査は、人々未知(たぶんBBNの)によってエコーホストが非常に早くIPの発展で創造されたと示唆します。 エコーホストを創造した人々に感謝します、そして、彼らの発明について説明する際にどんな誤りも謝りたいと思います。

Author's Address

作者のアドレス

   Craig Partridge
   BBN Corporation
   10 Moulton St
   Cambridge MA 02138

クレイグヤマウズラBBN社10のモールトン通りケンブリッジMA 02138

   EMail: craig@bbn.com

メール: craig@bbn.com

Partridge                     Experimental                      [Page 5]

ヤマウズラ実験的です。[5ページ]