RFC1055 日本語訳

Network Working Group                                          J. Romkey
Request for Comments: 1055                                     June l988

Romkeyがコメントのために要求するワーキンググループJ.をネットワークでつないでください: 1055年6月のl988

 A NONSTANDARD FOR TRANSMISSION OF IP DATAGRAMS OVER SERIAL LINES: SLIP

IPデータグラムのトランスミッションに標準的でないシリアル・ラインで: メモ用紙

INTRODUCTION

序論

   The TCP/IP protocol family runs over a variety of network media:
   IEEE 802.3 (ethernet) and 802.5 (token ring) LAN's, X.25 lines,
   satellite links, and serial lines.  There are standard encapsulations
   for IP packets defined for many of these networks, but there is no
   standard for serial lines.  SLIP, Serial Line IP, is a currently a de
   facto standard, commonly used for point-to-point serial connections
   running TCP/IP.  It is not an Internet standard.  Distribution of
   this memo is unlimited.

TCP/IPプロトコルファミリーはさまざまなネットワークメディアに目を通します: 802.5個(トークンリング)のIEEE802.3(イーサネット)、LANのもの、X.25系列、衛星中継、およびシリアル・ライン。 これらのネットワークの多くのために定義されたIPパケットのための標準のカプセル化がありますが、シリアル・ラインの規格は全くありません。 SLIP、Serial線IP、現在、aはTCP/IPを実行する二地点間連続の接続に一般的に使用されるデファクトスタンダードですか? それはインターネット標準ではありません。 このメモの分配は無制限です。

HISTORY

歴史

   SLIP has its origins in the 3COM UNET TCP/IP implementation from the
   early 1980's.  It is merely a packet framing protocol: SLIP defines a
   sequence of characters that frame IP packets on a serial line, and
   nothing more. It provides no addressing, packet type identification,
   error detection/correction or compression mechanisms.  Because the
   protocol does so little, though, it is usually very easy to
   implement.

SLIPは1980年代前半から3COM UNET TCP/IPインプリメンテーションで起源を発します。 それは単にパケット縁どりプロトコルです: SLIPはシリアル・ラインの上でIPパケットを縁どるキャラクタの系列、およびそれ以上何もを定義します。 それは扱わない、パケットタイプ確認、誤り検出/修正または圧縮機構を提供します。もっとも、プロトコルがそう少ししかしないので、通常、実装するのは非常に簡単です。

   Around 1984, Rick Adams implemented SLIP for 4.2 Berkeley Unix and
   Sun Microsystems workstations and released it to the world.  It
   quickly caught on as an easy reliable way to connect TCP/IP hosts and
   routers with serial lines.

1984年頃に、リック・アダムスは、4.2台のバークレーUnixとサン・マイクロシステムズワークステーションのためにSLIPを実装して、それを世界にリリースしました。 それはTCP/IPホストとルータをシリアル・ラインに接続する簡単な信頼できる方法としてすぐに引っかかりました。

   SLIP is commonly used on dedicated serial links and sometimes for
   dialup purposes, and is usually used with line speeds between 1200bps
   and 19.2Kbps.  It is useful for allowing mixes of hosts and routers
   to communicate with one another (host-host, host-router and router-
   router are all common SLIP network configurations).

SLIPは専用連続のリンクと時々ダイアルアップ目的に一般的に使用されて、通常、1200ビーピーエスと19.2Kbpsの間のライン・スピードと共に使用されます。 ホストのミックスを許して、ルータがお互いにコミュニケートするのは、役に立ちます(ホスト兼ホスト、ホストルータとルータルータはすべて一般的なSLIPネットワーク・コンフィギュレーションです)。

AVAILABILITY

有用性

   SLIP is available for most Berkeley UNIX-based systems.  It is
   included in the standard 4.3BSD release from Berkeley.  SLIP is
   available for Ultrix, Sun UNIX and most other Berkeley-derived UNIX
   systems.  Some terminal concentrators and IBM PC implementations also
   support it.

SLIPはほとんどのバークレーのUNIXベースのシステムに利用可能です。それはバークレーからの標準の4.3BSDリリースで含められています。 SLIPはUltrix、Sun UNIX、および他のほとんどのバークレーによって派生させられたUNIXシステムに利用可能です。また、いくつかの端末の集中装置とIBM PC実装がそれをサポートします。

   SLIP for Berkeley UNIX is available via anonymous FTP from
   uunet.uu.net in pub/sl.shar.Z.  Be sure to transfer the file in
   binary mode and then run it through the UNIX uncompress program. Take

バイナリ・モードでファイルを移して、次に、UNIXを通してそれを実行するのを確信していた状態でバークレーUNIXがパブ/sl.shar.Z. Beでuunet.uu.netからの公開FTPで利用可能であるので、SLIPはプログラムを解凍します。 撮影

Romkey                                                          [Page 1]

RFC 1055                     Serial Line IP                    June 1988

Romkey[1ページ]RFC1055シリアル・ラインIP1988年6月

   the resulting file and use it as a shell script for the UNIX /bin/sh
   (for instance, /bin/sh sl.shar).

結果になるのは、UNIX/bin/sh(例えば、/bin/sh sl.shar)にシェルスクリプトとしてそれをファイルして、使用します。

PROTOCOL

プロトコル

   The SLIP protocol defines two special characters: END and ESC. END is
   octal 300 (decimal 192) and ESC is octal 333 (decimal 219) not to be
   confused with the ASCII ESCape character; for the purposes of this
   discussion, ESC will indicate the SLIP ESC character.  To send a
   packet, a SLIP host simply starts sending the data in the packet.  If
   a data byte is the same code as END character, a two byte sequence of
   ESC and octal 334 (decimal 220) is sent instead.  If it the same as
   an ESC character, an two byte sequence of ESC and octal 335 (decimal
   221) is sent instead.  When the last byte in the packet has been
   sent, an END character is then transmitted.

SLIPプロトコルは2つの特殊文字を定義します: 終わりとESC。 ENDが8進300であり(10進192)、ESCが混乱しない8進333である(10進219)、ASCII ESCapeキャラクタ。 この議論の目的のために、ESCはSLIP ESCキャラクタを示すでしょう。 パケットを送るために、SLIPホストはパケットで単にデータを送り始めます。 1データ・バイトがENDキャラクタと同じコードであるなら、代わりにESCと8進334(10進220)の2バイト列を送ります。 それである、ESCキャラクタと同じです、代わりにESCと8進335(10進221)の2バイト列を送ります。 パケットにおける最後のバイトを送ったなら、ENDキャラクタを伝えます。

   Phil Karn suggests a simple change to the algorithm, which is to
   begin as well as end packets with an END character.  This will flush
   any erroneous bytes which have been caused by line noise.  In the
   normal case, the receiver will simply see two back-to-back END
   characters, which will generate a bad IP packet.  If the SLIP
   implementation does not throw away the zero-length IP packet, the IP
   implementation certainly will.  If there was line noise, the data
   received due to it will be discarded without affecting the following
   packet.

フィルKarnはアルゴリズムへの簡単な変化を勧めます。(アルゴリズムはENDキャラクタを伴う終わりのパケットと同様に始まることになっています)。 これは回線雑音によって引き起こされたどんな誤ったバイトも洗い流すでしょう。 正常な場合では、受信機は単に2つの背中合わせのENDキャラクタに会うでしょう。(キャラクタは悪いIPパケットを生成するでしょう)。 SLIP実装がゼロ・レングスIPパケットを捨てないと、確かに、IP実装は捨てるでしょう。 回線雑音があったなら、以下のパケットに影響しないで、それのため受け取られたデータは捨てられるでしょう。

   Because there is no 'standard' SLIP specification, there is no real
   defined maximum packet size for SLIP.  It is probably best to accept
   the maximum packet size used by the Berkeley UNIX SLIP drivers: 1006
   bytes including the IP and transport protocol headers (not including
   the framing characters).  Therefore any new SLIP implementations
   should be prepared to accept 1006 byte datagrams and should not send
   more than 1006 bytes in a datagram.

'標準'のSLIP仕様が全くないので、どんな全く定義されたSLIPに、最大のパケットサイズもありません。 バークレーUNIX SLIPドライバーによって使用された最大のパケットサイズを受け入れるのはたぶん最も十分です: IPと輸送を含む1006バイトがヘッダーについて議定書の中で述べます(縁どりキャラクタを含んでいなくて)。 したがって、どんな新しいSLIP実装も、1006年のバイトのデータグラムを受け入れるように準備されるべきであり、データグラムを1006バイト以上送るべきではありません。

DEFICIENCIES

欠乏

   There are several features that many users would like SLIP to provide
   which it doesn't.  In all fairness, SLIP is just a very simple
   protocol designed quite a long time ago when these problems were not
   really important issues.  The following are commonly perceived
   shortcomings in the existing SLIP protocol:

多くのユーザが提供するそれがそうしないSLIPのようにそうするいくつかの特徴があります。 公平に見て、SLIPがただかなり長い時に設計された非常に簡単なプロトコルである、前、これらの問題が本当に重要な問題でなかったときに。 以下は既存のSLIPプロトコルの短所であると一般的に知覚されます:

      - addressing:

- アドレシング:

         both computers in a SLIP link need to know each other's IP
         addresses for routing purposes.  Also, when using SLIP for
         hosts to dial-up a router, the addressing scheme may be quite
         dynamic and the router may need to inform the dialing host of

SLIPリンクの両方のコンピュータは、互いのIPがルーティングのために目的を扱うのを知る必要があります。 また、ダイヤルしているホストに知らせますホストにダイヤルアップaルータにSLIPを使用して、アドレシング体系がいつかなりダイナミックであるかもしれないか、そして、ルータが、必要があるかもしれない。

Romkey                                                          [Page 2]

RFC 1055                     Serial Line IP                    June 1988

Romkey[2ページ]RFC1055シリアル・ラインIP1988年6月

         the host's IP address.  SLIP currently provides no mechanism
         for hosts to communicate addressing information over a SLIP
         connection.

ホストのIPアドレス。 ホストがSLIP接続の上で情報を扱いながら交信するように、SLIPは現在、メカニズムを全く提供しません。

      - type identification:

- 識別をタイプしてください:

         SLIP has no type field.  Thus, only one protocol can be run
         over a SLIP connection, so in a configuration of two DEC
         computers running both TCP/IP and DECnet, there is no hope of
         having TCP/IP and DECnet share one serial line between them
         while using SLIP.  While SLIP is "Serial Line IP", if a serial
         line connects two multi-protocol computers, those computers
         should be able to use more than one protocol over the line.

SLIPには、タイプ分野が全くありません。 したがって、SLIP接続の上に1つのプロトコルしか実行できないので、TCP/IPとDECnetの両方を実行する2台の12月のコンピュータの構成には、SLIPを使用している間、TCP/IPとDECnetにそれらの間で1個のシリアル・ラインを共有させるという望みが全くありません。 SLIPは「シリアル・ラインIP」ですが、シリアル・ラインが2台のマルチプロトコルコンピュータを接続するなら、それらのコンピュータは系列の上で1つ以上のプロトコルを使用するはずであることができます。

      - error detection/correction:

- 誤り検出/修正:

         noisy phone lines will corrupt packets in transit. Because the
         line speed is probably quite low (likely 2400 baud),
         retransmitting a packet is very expensive.  Error detection is
         not absolutely necessary at the SLIP level because any IP
         application should detect damaged packets (IP header and UDP
         and TCP checksums should suffice), although some common
         applications like NFS usually ignore the checksum and depend on
         the network media to detect damaged packets.  Because it takes
         so long to retransmit a packet which was corrupted by line
         noise, it would be efficient if SLIP could provide some sort of
         simple error correction mechanism of its own.

騒がしい電話回線はトランジットでパケットを崩壊させるでしょう。 ライン・スピードがたぶんかなり低いので(2400年のありそうなボー)、パケットを再送するのは非常に高価です。 どんなIPアプリケーションも破損しているパケットを検出するべきであるので(IPヘッダー、UDP、およびTCPチェックサムは十分であるべきです)、誤り検出はSLIPレベルで絶対に必要ではありません、NFSのようないくつかの一般的なアプリケーションが、破損しているパケットを検出するために通常、チェックサムを無視して、ネットワークメディアによりますが。 回線雑音で崩壊したパケットを再送するにはあまりに長い間かかるので、SLIPがそれ自身のある種の簡単なエラー修正メカニズムを提供できるなら、効率的でしょうに。

      - compression:

- 圧縮:

         because dial-in lines are so slow (usually 2400bps), packet
         compression would cause large improvements in packet
         throughput. Usually, streams of packets in a single TCP
         connection have few changed fields in the IP and TCP headers,
         so a simple compression algorithms might just send the changed
         parts of the headers instead of the complete headers.

ダイアルイン回線が非常に遅いので(通常2400年のビーピーエス)、パケット圧縮はパケットスループットにおける大きい改良を引き起こすでしょう。 通常、単独のTCP接続におけるパケットの流れがIPとTCPヘッダーにわずかな変えられた分野しか持っていないので、簡単な圧縮アルゴリズムはただ完全なヘッダーの代わりにヘッダーの変えられた一部を送るかもしれません。

   Some work is being done by various groups to design and implement a
   successor to SLIP which will address some or all of these problems.

いくらかの仕事が、これらの問題のいくつかかすべてを扱うSLIPの後継者を設計して、実装するために様々なグループによって行われています。

Romkey                                                          [Page 3]

RFC 1055                     Serial Line IP                    June 1988

Romkey[3ページ]RFC1055シリアル・ラインIP1988年6月

SLIP DRIVERS

メモ用紙ドライバー

   The following C language functions send and receive SLIP packets.
   They depend on two functions, send_char() and recv_char(), which send
   and receive a single character over the serial line.

以下のC言語機能は、SLIPパケットを送って、受けます。 彼らは2つの機能に依存して、_炭()とrecv_炭()を送ってください。(それは、シリアル・ラインの上を単独のキャラクタに送って、受けます)。

   /* SLIP special character codes
    */
   #define END             0300    /* indicates end of packet */
   #define ESC             0333    /* indicates byte stuffing */
   #define ESC_END         0334    /* ESC ESC_END means END data byte */
   #define ESC_ESC         0335    /* ESC ESC_ESC means ESC data byte */

/*SLIP特殊文字コード*/#が定義する、END0300/*は、*/#、が定義するパケットでは、ESC0333/*が、*/#、を詰めるバイトがESC_END0334/*ESC ESC_ENDを定義するのを示す終わりが、ENDデータバイト*/#がESC_ESC0335/*ESC ESC_ESC手段ESCデータ・バイト*/を定義することを意味するのを示します。

   /* SEND_PACKET: sends a packet of length "len", starting at
    * location "p".
    */
   void send_packet(p, len)
           char *p;
           int len; {

/*は_パケットを送ります: *位置「p」で始まって、長さの"len"のパケットを送ります。 */空間は_パケット(p、len)炭*pを送ります。 int len。 {

     /* send an initial END character to flush out any data that may
      * have accumulated in the receiver due to line noise
      */
        send_char(END);

/*はそうするかもしれないどんなデータも洗う初期のENDキャラクタを送ります。*は回線雑音*のため受信機に蓄積しました。/は_炭(END)を送ります。

     /* for each byte in the packet, send the appropriate character
      * sequence
      */
           while(len--) {
                   switch(*p) {
                   /* if it's the same code as an END character, we send a
                    * special two character code so as not to make the
                    * receiver think we sent an END
                    */
                   case END:
                           send_char(ESC);
                           send_char(ESC_END);
                           break;

/、*パケットの各バイトのために、系列*/がゆったり過ごす適切なキャラクタ*を送ってください、(len--、)、(*p)を切り換えてください、*受信機に私たちがEND*/ケースENDを送ったと思わせないように、私たちは特別な2キャラクタコードをa*に送ります: _炭(ESC)を送ってください; _炭(ESC_END)を送ってください; *それであるなら、/はENDキャラクタと同じコードであり、壊れてください。

                   /* if it's the same code as an ESC character,
                    * we send a special two character code so as not
                    * to make the receiver think we sent an ESC
                    */
                   case ESC:
                           send_char(ESC);
                           send_char(ESC_ESC);
                           break;

**それであるなら/がESCキャラクタと同じコードである、私たちは特別な2キャラクタコードを送って、したがって、作るどんな*としても、受信機は私たちがESC*/ケースESCを送ったと考えません、: _炭(ESC)を送ってください。 _炭(ESC_ESC)を送ってください。 壊れてください。

Romkey                                                          [Page 4]

RFC 1055                     Serial Line IP                    June 1988

Romkey[4ページ]RFC1055シリアル・ラインIP1988年6月

                   /* otherwise, we just send the character
                    */
                   default:
                           send_char(*p);
                           }

さもなければ、私たちがただキャラクタ*/デフォルトを送る/*: _炭(*p)を送ってください。 }

                   p++;
                   }

p++。 }

           /* tell the receiver that we're done sending the packet
            */
           send_char(END);
           }

/*は、私たちが_炭(END)を/が送るパケット*に送り終わっていると受信機に言います。 }

   /* RECV_PACKET: receives a packet into the buffer located at "p".
    *      If more than len bytes are received, the packet will
    *      be truncated.
    *      Returns the number of bytes stored in the buffer.
    */
   int recv_packet(p, len)
           char *p;
           int len; {
           char c;
           int received = 0;

/*RECV_パケット: 「p」に位置するバッファの中にパケットを受けます。 * *受け取られたlenバイト、パケット以上がそうするなら、先端を切られてください。 * バイト数がバッファに保存したリターン。 */int recv_パケット(p、len)炭*p。 int len。 炭c; intは=0を受けました。

           /* sit in a loop reading bytes until we put together
            * a whole packet.
            * Make sure not to copy them into the packet if we
            * run out of room.
            */
           while(1) {
                   /* get a character to process
                    */
                   c = recv_char();

私たちが*a全体のパケットをまとめるまでの/*参加a輪の読書バイト。 * *余地から実行されて、私たちであるならパケットにそれらをコピーしないのを確実にしてください。 */が(1)をゆったり過ごす、/*で、キャラクタはrecv_*/c=炭()を処理します。

                   /* handle bytestuffing if necessary
                    */
                   switch(c) {

必要なら*/スイッチ(c)をbytestuffingする/*ハンドル

                   /* if it's an END character then we're done with
                    * the packet
                    */
                   case END:
                           /* a minor optimization: if there is no
                            * data in the packet, ignore it. This is
                            * meant to avoid bothering IP with all
                            * the empty packets generated by the
                            * duplicate END characters which are in

*それであるなら、/はENDキャラクタです、次に、私たちが処理されます。*パケット*/はENDをケースに入れます: /*a小さい方の最適化: *データが全くパケットになければ、それを無視してください。 これは空のパケットが*写しENDキャラクタで中のすべての*を生成していてIPを苦しめるのを避けることになっていた*です。

Romkey                                                          [Page 5]

RFC 1055                     Serial Line IP                    June 1988

Romkey[5ページ]RFC1055シリアル・ラインIP1988年6月

                            * turn sent to try to detect line noise.
                            */
                           if(received)
                                   return received;
                           else
                                   break;

* 送るのにターンして、回線雑音を検出しようとしてください。 *(受け取られている)であるなら、/は受け取られていた状態で戻ります。 ほかに、壊れてください。

                   /* if it's the same code as an ESC character, wait
                    * and get another character and then figure out
                    * what to store in the packet based on that.
                    */
                   case ESC:
                           c = recv_char();

*それであるなら、/はESCキャラクタと同じコードです、そして、*を待ってください、そして、別のキャラクタを手に入れてください、そして、次に、*それに基づくパケットに何を保存したらよいか理解してください。 */ケースESC: cはrecv_焦げ()と等しいです。

                           /* if "c" is not one of these two, then we
                            * have a protocol violation.  The best bet
                            * seems to be to leave the byte alone and
                            * just stuff it into the packet
                            */
                           switch(c) {
                           case ESC_END:
                                   c = END;
                                   break;
                           case ESC_ESC:
                                   c = ESC;
                                   break;
                                   }

*「c」であるなら、/はこれらの2の1つでなく、その時は私たちです。*プロトコル違反を持ってください。 *がバイトを放っておくことになっているように思えるのが賭けられたベストと*はただパケット*/スイッチ(c)にそれを詰めます。ESC_ENDをケースに入れてください: cはENDと等しいです; 壊れてください; ESC_ESCをケースに入れてください: cはESCと等しいです; 壊れてください;。

                   /* here we fall into the default handler and let
                    * it store the character for us
                    */
                   default:
                           if(received < len)
                                   p[received++] = c;
                           }
                   }
           }

/、**ここで、私たちがデフォルト操作者になって、貸されて、私たちのためにキャラクタを保存する、*/デフォルト: (<lenを受けます)p[+ +を受ける]がcと等しいなら。 } } }

Romkey                                                          [Page 6]

Romkey[6ページ]