連載 /NET WORTH—@ ~ 1552 ) [ 6 ー -22 ] で文書化されている。 1993 年 12 月に出 た RFC1547 ~ 1549 [ 17 ー 19 ] 3 を読むとよい。 RFC は、 ds. InterNic. net の /rfc など多くのサイトから anony- mous FTP で入手できる。 PPP に関する有益な FAQ (Frequently-Asked Question) が、 rtfm.mit.edu の / pub/usenet/news. answers/ppp-faq から anonymous FTP で入手できる。 自宅から Mosaic を動かしたり、ネットワーク・オー ディオキャスト (network audiocast) を聴いて暇潰しが できるように、私はさまざまな SLIP の実装をなだめす かしながら、なんとか年イせ勿の Cisco ターミナル・サー バーに接続しようとしている。ダイヤルアップ接続をする のに、 SLIP と PPP のどちらでも選べるのなら、リモー トアクセスの虜にしてくれる PPP をお勧めする。 Suite 4200 , 1760 Zollinger Rd. , CoIumbus, Morning Star Technologies [ 本文中で紹介されたべンダーの連絡先 ] OH 43321 , U. S. A. (Tel 十 1 ー 614 ー 451 ー 1883 ) Brixton Systems 185 AIewife Brook Pkwy. , MA 02138 , U. S. A. (Tel 十 1-617 ー 547 ー 9820 ) [ 赭文献 ] [ 1 ] Lars Poulsen and Bill Simpson, Cambridge, "PPP Takes Over ” UNIX REVIEW, September 1993 , pp. 45 [ 2 ] W.Richard Stevens, TCP/IP lllustrated, Volume 1 , Addison-Wesley, 1993 [ 3 ] Craig Hunt, TCP/IP Network Administration, O'Reilly & Associates, 1992 ( 邦訳 : 村井純監訳 『 UNIX システム管理者のための TCP/IP ネットワーク管 、オーム社、 1994 年 ) [ 4 ] J. Romkey, Nonstandard for transmission of IP datagrams over serial lines: SLIP RFC1055 , June 1988 [ 5 ] V. Jacobson, Compressing TCP/IP headers for low- speed serial links RFC1144 , February 1990 [ 6 ] Ⅵを Simpson, The Point-to-Point Protoc01 (PPP) for the Transmission of Mu れ r0t0C07 Datagrams over Point-to-Point Links, RFC1331 , May 1992 (Obso- leted by RFC1548 , RFC1661 ) 3 訂主 : RFC1547 ~ 1548 は、すでに RFC1661 ~ 1662 に置き換え られな 56 [ 7 ] G. McGregor, The PPP lnternet Protocol Control Protocol (IPCP), RFC1332 , May 1992 [ 8 ] Ⅵを Simpson, PPP Link Quality Monitoring, RFC1333 , May 1992 [ 9 ] B. Lloyd and Ⅵ匚 Simpson, PPP Authentication Protocols, RFC1334 , October 1992 [ 10 ] S. Senum, The PPP DECnet Phase IV ControI Pro- tocol (DNCP), RFC1376 , November 1992 [ 11 ] D. Katz, The PPP OSINetwork Layer Control Pro- tocol (OSINLCP), RFC1377 , November 1992 [ 12 ] B. Parker, The PPP AppIeTaIk ControI ProtocoI (ATCP), RFC1378 , November 1992 [ 13 ] F. Kastenholz, The Definitions ofManaged Objects for the Link Contr01 Protocol of the Point-to-Point Protocol, RFC1471 , June 1993 [ 14 ] F. KastenhoIz, The Definitions of Managed Objects for the Security Protocols ofthe Point-t0-P0int Pro- tocol, RFC1472 , June 1993 [ 15 ] F. Kastenholz, The Definitions of Managed Objects for the IP Network Control Protocol of the Point- to-Point Protocol, RFC1473 , June 1993 [ 16 ] F. Kastenholz, The Definitions of Managed Ob- jects for the Bridge Network Control Protocol of the Point-to-Point Protocol, RFC1474 , June 1993 [ 17 ] D. Perkins, Requirements for an lnternet Standard Point-to-Point Protocol, RFC1547 , December 1993 [ 18 ] 、 V. Simpson, The Point-to-P0int Protocol (PPP), RFC1661 , July 1994 (Obsoletes RFC1548 ) [ 19 ] 、 V. Simpson, PPP ⅲ HDLC Framing, RFC 1662 , JuIy 1994 (ObsoIetes RFC1549 ) [ 20 ] S. Bradner and A. Mankin, IP: Next Generation (IPng) White Paper SoIicitation, RFC1550 , Decem- ber 1993 [ 21 ] M. Allen, Nove11 IPX Over Various WAN Media (IPXWAN), RFC1551 , December 1993 (Obsoleted by RFC1634 , May 1994 ) [ 22 ] 、 V. Simpson, The PPP lnternetwork Packet Ex- change Control l)rotocol (IPXCP), RFC1552 , De- cember 1993 州の建物のエネルギー管理をおこなうオレゴン州エネルギー省勤務。 CProgrammer's JournalJ の : 兀編集者であり、 CExtending DOSJ (Addison-Wesley 刊、 1990 ) の著者の 1 人でもある。 「 Remote Access With SLIP And PPP 」 UNIX REVIEW 1994 年 3 月号より ◎ 1994 , UNIX REVIEW(). S. A. ) ■ M. Steven Baker UNIX MAGAZINE 1995.4

連載 /UNIX Communication Notes—@ MIB は、 1 つの大きな冓造を形成する空間を定義し ている。各管理対象ノードは、この冓造に対応したすべ てのデータをもつ必要はなく、関連する部分だけをもてば よい。 このオ冓造をみていくと、ある枝は共通のデータ、ある 枝はルータについてのデータ、ある枝は ATM スイッチ についてのデータというように、対象の不頁ごとにまとめ られている。 ノート 2 これらの定義は、それぞオ・リ虫立した RFC として発行され ている。具ー勺な内容については、各 RFC を参考にしてもら いたい。 RFC1720 には一覧があるので、必要な MIB を探す のにイリである。 ☆ 今回は SNMP の概要を述べた。次回は、 MIB の構造 とそのモニタリングについて説明する。 ( やまぐち・すぐる奈良先端科我術大完大学 ) [ 赭文献 ] [ 1 ] M. SchoffstaII, M. Fedor, J. Davin, J. Case, A SimpIe Ⅳ et 0 Management ProtocoI (SNMP), RFC1157 , May 1990 [ 2 ] J. Case, K. McCIoghrie, M. Rose, S. WaIdbusser, / れ od 社 c 0 れ to ゼ er 0 れ 2 0 工 the lnternet-standard Ⅳ et 0 イ 0 れ ageme れ t Framework, RFC1441 , May 1993 [ 3 ] J. Case, K. McCIoghrie, M. Rose, S. WaIdbusser, St ロ肥 t 社 0 / イ佖れ佖 geme れめ / / 0 0 0 れ for e を 0 れ 2 可 the Simple Ⅳ et 0 祕 Management Protocol (SN- l'l イ P ゼ 2 去 RFC1442 , May 1993 [ 4 ] J. Case, K. McCloghrie, M. Rose, S. Ⅵ ld - busser, Tectual CO れむ e れ 0 れ s for ゼ er 0 れ 2 0 / the SimpIe ル 30 祕イ佖れ ageme れ Protocol ( S ルイ P ゼ 2 去 RFC1443 , May 1993 [ 5 ] J. Case, K. McCIoghrie, M. Rose, S. WaIdbusser, Conformance Statements for む ers を 0 れ 2 可 the Simple ル etwo 祕イ佖れ ageme れ t Protocol ( S Ⅳイ P ゼ 2 丿 , RFC1444 , May 1993 [ 6 ] J. Davin and K. McCIoghie, Administrative ModeI for version 2 可 the Simple ル etwo 法 Management ProtocoI (SNMPv2), RFC 1445 , May 1993 [ 7 ] J. GaIvin and K. McCloghrie, Sec 社 Protocols for ゼ e ”を 0 れ 2 可 the Simple Ⅳ etwo 祕イ 0 れ eme れ Pro- t08 ー ( S ル MPv2, 丿 , RFC1446 , May 1993 UNIX MAGAZINE 1995.4 [ 8 ] K. McCloghrie and J. GaIvin, P 佖リ MIB for 眦ル s れ 2 可 the & m 厄Ⅳ etwo 九一佖れ ageme れ t Protocol (SNMPv2), RFC 1447 , May 1993 [ 9 ] J. Case, K. McCIoghrie, M. Rose, S. WaIdbusser, Protocol Operations for version 2 可 the SimpIe Net- 30 Management Protocol ( S Ⅳイ P む 2 丿 , RFC1448 , May 1993 [ 10 ] J. Case, K. McCIoghrie, M. Rose, S. Ⅵ ld - busser, Tra れ s 〃 0 イ佖〃れ gs 工 br ゼ e れ 2 0 工 the SimpIe Ⅳ et 0 Ma れ eme れカ ProtocoI ( S ルイ p む 2 丿 , RFC1449 , May 1993 [ 11 ] J. Case, K. McCIoghrie, M. Rose, S. WaIdbusser, イ 0 れ ageme れ / れ / 0 m 0 れ Base 工 br の e 0 2 0 / the SimpIe Ⅳ etwo 祕 Management ProtocoI ( S ルイ p ゼ 2 去 RFC1450 , May 1993 [ 12 ] J. Case, K. McCIoghrie, M. Rose, S. WaIdbusser, イ 0 れ 04e to イ 0 れ ager イ佖れ geme t / 〃工 0 れ 0 0 れ Base, RFC1451 , May 1993 [ 13 ] J. Case, K. McCIoghrie, M. Rose, S. WaIdbusser, Coecistence between ゼ ers を 0 〃プ佖〃 d ers を 0 れ 2 0 工 the れ te 肥 sta れ d 佖ル etwo 祕イ 0 れ佖 geme れ t Frame- 30 祕 , RFC1452 , May 1993 [ 14 ] K. McCloghrie and M. Rose, Structure 0 れ d 〃 e れ - 五 ca 0 れ可スイ 0 れ ageme れ / れル " れ佖 0 れル TCP/IP- based ん tet e な , RFC1155 , May 1990 [ 15 ] K. McCloghrie and M. Rose, Concise MIB De 五れを - 0 れ s , RFC1212 , Mar. 1991 [ 16 ] K. McCloghrie and M. Rose, Management ー〃 / 0 た ma 0 れ Base ルル et 0 イ 0 れ佖 geme れ t 可 TCP/IP- based をれ te ロ託な : MIB-II, RFC1213 , Mar. 1991 [ 17 ] Jon PosteI, lnternet 0 か c I Protocol Sta れ da , RFC1720 , Nov. 1994 31

連載 /NET WORTH—@ が、 1993 年 12 月に去斤の RFCI が発行された。初めて PPP を実装したのは、カリフォルニアた学サンディエゴ 校の Russ Hobby (DOS KA9Q 用 ) と CMU の Drew Perkins (BerkeIey UNIX 版 ) である。これら以、タ ) 実 装の大半は、おおむねこの 2 つをもとにしている。 PPP は、 Point-to-Point 接続においてマルチプロト コル・データグラムを転送するイ組みを備え、おもに次の 3 つの部分で SLIP での制限に対処している。 ・データグラムをカプセル化する方法 ・ LCP (Link Control Protocol) ・ NCP (Network Control Protocol) PPP のデータリンク層は、同期データ中幻のため IBM などがさかんに利用している HDLC (High-level Data Link ControI) フォーマットにわすかな修正を加えたも のである。 PPP では、 HDLC に 16 ビットのプロトコル・ フィールドを加え、複数のネットワーク層のトラフィック を多重化できるようにした (NCP)O このカプセル化され たフレームは 16 ビットのチェックサムを使うか : チェッ クサム・フィールドの大きさはネゴシェーションによって 決まる。 LCP を用いて、完全なデータリンク・コネクションの 確立と成疋、テストをおこなう。 ) 」引の要不要、 IP アド レスなどのさまざまなパラメータは、 LCP によって重加勺 に : 夬定される。 IP 、 IPX 、 DECnet 、 OSI 、 AppleTalk などの主要なネットワーク・プロトコルの NCP があらか しめ定義されている [ 1 ] 。 PPP では、複数のプロトコルが単一の回線を流れる だけでなく、標準コマンドとその応答の状態表を使って リンク制御の取決めを明確に定義している。 LCP は、認 証やリンクの品質監視、圧縮のためのいくつかの手順も サポートしている。これらの機能のおかげで、 PPP 接続 でのデバッグは SLIP にくらべてかなり楽になっている が、いくっかの間題カ戦されている。シリアル回線は、リ モートログインと PPP の両方で利用されるかもしれな いからだ。単一の回線に複数のプロトコルを流せたらす ばらしいのだが、現在の PPP の実装では、 2 つ以上の NCP をサポートしているものはほとんどなく、たいてい 1 調主 : 工第点での PPP に関する去斤の RFC ーよ RFC1661 ( 1994 年 7 月 ) と RFC1662 ( 1994 年 7 月 ) である。 54 は IP のみに対応している。いくつかのプラットホーム (UnixWare 、 NetWare など ) のべンダーは、将来、 IPX と IP をサポートすると表明している。 実装 ーヨ殳に、 SLIP と PPP はモデムを通して音声回線て利 用される。この場合、転送すべきバケットが発生すると、 要求に応してダイヤルしてコネクションを張り、しはらく 何もしない状態カくとコネクションを切るプログラムが 堋想的だろう。ネットワーク接続に長距旧凾話を必喫とし たり、接続間で課金する商用インターネット・プロバイ ダを利用するなら、この機能はとくに重要であり、費用の 節約にもなる。 SLIP や PPP の実装では、特定のバケッ ト (RIP や ICMP などのバケット ) を通さない機能が必 要で、不必要なダイヤルをおこなったり、必要以 - E にコネ クションを系早したりすべきではない。商用の SLIP や PPP には要求時にダイヤルする機能が実装されているが、 フリーのものでこうした機能を備えているのは数えるはど しかない。 ダイヤルアッフ。接続では、自分の利用するネットワーク と外部の電話システムとのあいだにきちんと機能するルー タが介在することは稀である。このような場合、システム 管理者なら、プロトコルと接続 IP アドレスのどちらか、 または両方にもとづいた ( ルータと同様の ) バケットのフ イルタリンク幾能が必要だと思うだろう。このトラフィッ クはたいてい一ヨ殳の電話回線 - E を流れるので、機密情報を 扱うのならデータの暗号化か必頭になる。こうした機能を 備えているのは、通常、商用の PPP や SLIP の実装だ けである。 リモートアクセスをするため、 SLIP と ppp の実装 をいくつか試用してみた。現在、さまざまなべンダーか ら UNIX 用のム万版 PPP か販売されている。 SunSoft は、 SPARC 用 Solaris 2.4 に PPP を標忝付してお り、 Novell は、 X86 アーキテクチャ用 UnixWare 1.1 に PPP と SLIP を入れている。設定や接続、運用で問 題を抱えたユーサーからの記事が、いくつかのニュースグ ノレーフ。 (comp ・ protocols. ppp 、 comp. os. s01aris2 、 comp ・ sys. sun) に財高されている。 現在のところ、 UNIX 用の SLIP を販売しているサー UNIX MAGAZINE 1995.4

ーの 連載 /UNIX Communication NOtes ドからネットワーク管理ステーションへの割込みと捉えら ションがあってもかまわない。 管理情剌をヾース (Management lnformation Base: MIB) 管理対象ノード刎青報を言求するためのデータベースの 構造を規定する。したがって、管理対象ノードとネッ トワーク管理ステーションでは同し MIB が使われる。 ー殳に、データベースは各管理対象ノードごとに用意さ はかのノードと共有していたり、あるいは全体で 1 つの分散データベースを形成することはない。 操作とモニタリンク SNMP による操作とモニタリングでは、 j 鬲デバッグ (remote debugging) という考え方か探り入れられてい る。 ・各管理対象ノードは、、変数 " をもつ。 ・ネットワーク管理ステーションは、各管理対象ノードの 変数を参照したり、値を設定することかできる。 ・変数の値の参照は、管理対象ノードのモニタリングを意 味する。 ・変数の値の変更は、その管理対象ノードに対する操作を 未する。 ・そして、この変数の組を定義するのが MIB である。 具体例を示そう。たとえば、管理対象ノードの MIB に、 P 。 werOn " という変数があったとしよう。この変数 の値が 1 であれば ( 何かの ) 電源が入っており、 0 であれ ば切れているとする。ネットワーク管理ステーションは、 SNMP を用いて PowerOn の値を間い合わせ、電源が 入っているかどうかを知ることができる ( つまり、電源の モニタリングができる ) 。さらに、 PowerOn の値を 1 か ら 0 に書き換えれば、電源を切るという操作をしたことに なる。逆に 0 から 1 に書き換えれば、電源を投入すると いう未になる。 トラップ ネットワーク管理に必要な処理として、トラップ (trap) がある。これは、管理対象ノードがなんらかの状 態の変化をネットワーク管理ステーションに伝えるために 使われる。事前に設定された牛を管理対象ノードか満た した場合、指定されたネットワーク管理ステーションに 対して伝えるかたちになっている。いわば、管理対象ノー 30 れる。 コミュニティ いる。詳しくは、 RFC1720 [ 17 ] を参照してはしい。 は、 RFC1155 [ 14 ] 、 1212 [ 15 ] 、 1213 [ 16 ] などで定義されて 情報を記述するデータベースの構造を定めている。これ さきはども述べたように、 MIB では管理対象ノードの MIB に言当されている。 SNMPv2 の内容は、 RFC1441 [ 2 ] ~ 1452 [ 13 ] の各 RFC SNMP のプロトコルは、 RFC1157 [ 1 ] で定義されている。 れている。ポート番号には、 161 と 162 が使用される。 として使うアプリケーション層プロトコルとして定義さ 現在の SNMP は、一ヨ殳に UDP をトランスポート層 その他 らのほうがよい。 が SNMPv2 に対応しているかどうかを十分にチェックしてか したがって、利用する予定なら、対象となるネットワーク機器 ているが、 SNMPv2 が実装されていない製品はかなりある。 在、 SNMP ははとんどすべてのネットワーク機器に実装され トワーク機器が SNMPv2 に対応しているわけではない。現 く、 SNMPv2 も併用したほうがよい。ただし、すべてのネッ 部からの SNMP バケットをスクリーニングするだけではな に配慮しなければならない場合は、ファイアウォールで系レト MPv2 (SNMP version2) も開発されている。セキュリティ あった。そこで、 SNMP のセキュリティ機能を強化した SN- コミュニティを用いたアクセス制脚には、多くの問題点が も避けるべきである。 開してはならない。パスワードと同様、簡単に推測できるもの コミュニティ名はパスワードに相当するので、むやみに公 どうかを判断する。 ミュニティ名をみて、変数の参照・変更をさせてもよいか では、ネットワーク管理ステーションから送られてきたコ きる。コミュニティは文字列て表され、管理対象ノード コミュニティごとに変数の参照およひ変更の・可否を設定で かどうかなどのアクセス制御に使われる。 SNMP では、 がある。これは、変数の値の設定やトラップを受け付ける SNMP には、コミュニティ (community) という児念 UNIX MAGAZINE 1995.4

連載 / IJN Ⅸの首具箱ー① トに詳しい説明があるので、そちらを参照してください。 を探し、なけれは /etc/ppp ・ conf を参照します。っ このはかにも、 PPP プログラムの状態遷移が / var / まり、ホームディレクトリに . ppp ・ conf があると、 /etC/PPP ・ conf を変更しても反映されないのです 16 10g/PPP ・ log に言泉されます。かならずしもトラブル解 決に茁妾役に立つわけではありませんが、 PPP の動作を 「いくら設定しても全然変わらへん」という場合には、 理解したいと思う方は一度眺めてみるといいでしよう。 この点をチェックしてみましよう。 ・ PPP 用のアカウントのログインシェルは実行可能にな っているか。 ・ PPP 用のアカウントのホームディレクトリにある . hushlogin や . ppp. conf ファイノレの戸斤有者やノヾー ッションは正しいか。 疋ファイルの内容は正しいか。 シリアルテンヾイスのファイル名や電話番号、ログイン 名、パスワードなどは正しく設定されていますか。さら [ 赭文献 ] に、ローカル側とリモート側の両方で IP アドレスを [ 1 ] 大野俊治「 PPP の使い方 Version 0.93 」、 1994 年 10 月 設定している場合、両者に喰違いがないかを石忍しまし 11 日 [ 2 ] Ⅵを Simpson, The Po をれ to - Po t Protocol (PPP) 和 7 、 the 石、佖れ sm な s 0 れ可 Multi-protocol Datagrams 0 ゼ er 、 対話モードでは show コマンドを使って、現在の状 Po t - - Po んん s , RFC1331 , May 1992 [ 3 ] G. McGregor, The PPP んロ肥め ProtocoI Control 態などを表示させることができます。たとえば図 11 で Protocöl (IPCP), RFC1332 , May 1992 は、、 show proto" を実行し、各プロトコルの統言 - H 青報を [ 4 ] 、 V. Simpson, PPP んをれん Q 社 0 〃匆んⅲれ 9 , 表示させています 17 。その他については伺属のドキュメン RFC1333 , May 1992 16 和たちも糸があります。 [ 5 ] B. Lloyd and Ⅵを Simpson, PPP ス社 t ん e れ c 佖 0 れ Pro- 17 図 11 ではバケットの通信機能 (Predictor-1) を使っているの co な , RFC1334 , Oct. 1992 で、 IP バケットは COMPD の欄に討・されています。 [ 6 ] Ⅵを Simpson, The P れ t - - Po t Protocol (PPP), RFC1661 , Dec. 1993 WEnet の利用方法 ロンプトか表示されます。この場合は何も入力せずにリターン キーを押し、、 login: " プロンプトか表示されてから、改めて wenet と入力してください。 冫も意 収容しているプログラムの利用や再配布にあたっては、各ソ フトウェアのドキュメントにある孑気こ従い、作者に迷惑をか けないようにしてください。 当サービスより入手したソフトウェアの使用によって発生 したデータ、機器などの損害章害、その他のイ隘について、 UNIX MAGAZINE 編集部ならびに ( 株 ) アスキーはいっ さいの責任を負いません。 WEnet に対するご意見、ご要望などは、かならす書面で下 己の宛先にお送りください。 〒 151-24 東京者を区代々木 4-33-10 材に会社アスキー UNIX MAGAZINE 黻部「 WEnet 」係 FAX 03-5371-7447 今回はルーティングまでを予定していたのですが、 iij- ppp の説明だけで誌面が尽きてしまいました。次回こそ ルーティングについて角見する予定です。 ( おカ呻ま・きよひこ、かたやま・よしあき 奈良先立斗 ! 物支術大完大学 ) 本誌では、電話回線を利用したフリー・ソフトウェアなど の配布サーピスをおこなっています。 配布サービスを希望する方は、編集部のホスト (WEnet) にモデム経由でログインし、希望するソフトウェアなどをダウ ンロードしてください。事前の申込み、パスワードの当求など は必ありません。接続料・金は通言辞ト金を除き無料です。 運用 午前 8 時 30 分 ~ 舸変 2 時 40 分 変 3 時 10 分 ~ 舸 9 時 定期メンテナンス 毎週月曜日 アクセス号 第 1 回線 03-5351-8117 第 2 回線 03-5351-8118 ( 9 , 600bps 、 MNP5 、 V. 42 / V. 42bis / V. 32 ) ログイン 接続カ院了したらログイン名、、 wenet " を入力し、リター ンキーを押します。ログイン名を間違えると、 "Passwd:" プ 一三ロ 95 UNIX MAGAZINE 1995.4

連載 / UN Ⅸの道具箱 - ① 表 1 iij-ppp version 0.93 の配布キットとパッチの入手先 サイト ftp.iij.ad.jp ftp.astec.co. JP ディレクトリ /pub/network/iij-ppp /pub/network/ppp/iij-ppp ftp.kuis.kyoto-u.ac.jp /ftpmail/ftp.iij.ad ・ jp/pub/network/iij-ppp 処理するプロセスはカーネル内に実装されていますが、 iij- ppp ではユーザープロセスとして・見されています。この ため、障售時のシステムへの景グを最小限に抑えることが 可能です。 このはかにも、際立った相違として以下の点か挙げられ ます。 ・文乱勺なユーザー・インターフェイス kermit に似たユーザー・インターフェイスカ甘是供さ 環境設定などが対言乱勺におこなえる。対話モードでコマ ンドを利用した接続の確立・切断のほかに、プロトコル の重川大況を知ることも可育 ・ 4 つのモードて動乍可能 対話モード : ューサーとの対話が可能 自動モード : デーモンとして重川乍 直接モード : tty との入出力を茁妾おこなう 専用線モード : 専用妾続に対応 ・自宅から面な PPP が可能 対応する OS は、 BSD/OS 1.1 、 FreeBSD 1.1 で 2 、 PC 上で UNIX を利用している場合は少ない費用です む ( といっても、タダではありませんが・・ ・ On-demand dialup 機肯劼可能 自動モードで重川乍させることにより、バケットの検出に よるダイヤリングが・可育邑アイドルタイマーを利用し、 バケットが一定時翩充れないと自重加勺に回線を遮析する 機能もある。 ・ telnet を不堋しての文囎舌モードも可能 iij-ppp に対してケえられた通信ポートに telnet て鮟続 して、 PPP プロセスを対言乱勺に操作することができる。 ・ RFC1331 、 1332 、 1333 、 1334 に文寸応 PPP に関する標準を定めた RFC13313 ~ 1334 [ 2 ー 5 ] に準拠しています。 2 version 0.94 から ( よ NetBSD 1.0 および FreeBSD 2.0 にも対 応しています。個別に NEXTSTEP や HP-UX にも対応しているそ うてす。 3 1995 年 2 月 5 日現在の PPP に関する去用阪は RFC1661 [ 6 ] です。 UNIX MAGAZINE 1995.4 ・バケットの圧縮通信皀をサポート Predictor Type-1 ( 以下、 Predictor-1 と略 ) 方式の バケットデータ刎下縮機能をサポートする。 ・バケットのフィルタリング皀をサポート バケットの送受信を禁止・許可するためのフィルタリン グ機能をもつ。 On-demand dialup のきっかけとなる バケットの不鶤頁も、フィルタによって制限できるにの 機能により電言辞ト金の節約か図れる ) 。 とくに On-demand dialup は、本格的な利用に必須 です。バケットの王縮機能も、中幻幻度の改善には欠かせ ません。ただし、接続した双方の PPP プログラムか 1 司し ) 王縮機能を備えていなけれは利用できません。 それでは、インストールの手順を説明します。 iij-ppp のインストーノレ ソースファイルは、表 1 に挙げた FTP サイトなどから 1. 配布キットの入手 順番にみていきましよう。 3. PPP プログラムのインストール 2. トンネルテンヾイスのインストール 1. 配布キットの入手 インストールイ乍業は、次の 3 つの段階に分けられます。 77 monkey@bsdi [ 2 ] $ cd iij -ppp0.93 monkey@bsdi [ 1 ] $ mkdir iij—pppO. 93 ディレクトリで作業する場合は、次のようになります。 レクトリを作り、そのなかで展開します。 iij-pppo ・ 93 や doc などのディレクトリができるので、作業用のディ の 2 つです。配布キットは、展開したディレクトリに src るパッチ ・ iij -pppO. 93-patch1 : iij-ppp version 0.93 にヌ寸す 類を含む ) ・ iij-ppp0.93. tar. gz: ソースキット ( ドキュメント 入手できます。必要なファイルは、

連載 /NET WORTH—@ 表 1 SLIP 、 PPP の置いてある anonymous FTP サイト ftp.ee.1b1.gov:/cslip3.7.tar.Z BSD 、 SunOS 用の日孫宿 SLIP ftp.uu.net:/networking/ip/slip さまざまなノヾージョンの SLIP ftp.uu.net:/networking/ip/ppp さまざまなシステム用の PPP merit.edu//pub/ppp/* phoenix.acn.purdue.edu//dp さまざまなシステム用の PPP SunOS 、 Solaris 2 用の PPP 国内の anonymous FTP サイトにも置いてあるソフトウェアもある。これらのサイト にアクセスする前に、 archie コマンドなどて市忍するとよい。 ドノヾーティーは Morning star Technologies だけ 2 で、 UNIX 用 PPP 製品も Morning Star と Brixton Sys- tems のものしかない。どちらの PPP 製品も、 1991 年 の半ばに登場し、現在では、要求時ダイヤル接続、認証、 ヘッタ第孫宿、リンク品質監視、バケット・フィルタリングを サポートしている。いくっかのプラットホーム (SunOS 、 Solaris など ) では、重加勺ローディング・ドライノヾ (dy- namically loadable driver) を用いるのでカーネルを再 構築する必要はない。 Morning Star の製品には、より細 かなバケット・フィルタリング制御といくぶん簡単に使え るデバッグとログ機能がある。 Morning Star の製品は、いくつかのフラットホーム (SPARC と Sun3 の SunOS 4 、 SoIaris 2. x SPARC 、 Ultrix 、 NEXTSTEP 、 SGI 、 AIX 、 HP-UX 、 SCO) に対応しており、 4 反売をおこなう商用インターネット・ プロバイダもある。 Morning star の ppp の構成は、 カーネル空間にインストールされる小さなドライバを除 けはユーサー空間のデーモンだけなので、新しいプラッ トホームへの移植も上交的簡単で、デバッグもそれほど 難しくない。高速接続 ( V. 35 インターフェイスを用いた 1.544Mbps の TI 接続 ) には不向きだが、普通のシリア ルポートとモデムでの利用には一ト分である。 DES データ 暗号化もサポートしている。 Brixton の PPP は、 HP-UX 、 SunOS 、 Solaris 2. x SPARC 、 Solaris 2.1 X86 、 AIX 、 SCO UNIX 、 UnixWare 、 Windows NT などのプラットホームでス トリーム対応の実装をしている。この PPP は完全にカー ネル内で実装され、高速 ()I 程度 ) で実行しても、かな りの能か得られるように設計してある。同期モードで、 SPARC のシリアルポートとさまざまな SBus カードを サポートしている。現在の Windows NT 版では、 pc のシリアルポートをそのまま利用することかて、きす、特別 UNIX MAGAZINE 1995.4 2 PPP ノヾッケージに含まれている。 なマルチボート・カードを使わなけれはならない。 UNIX 用のフリーな SLIP や PPP は、 anonymous FTP で入手できる ( 表 1 ) 。ほとんどは SunOS 、 BSD UNIX 、 X86 用 SVR4 . 対応のもので、カーネルの 4 嚇築 が必喫である。ところが、厄介なことにフリーの SLIP と PPP には、カーネルのド犲冓築、設定、インストール、デ バッグについての田なドキュメントがない。ここに挙げ たいくっかのソフトウェアはひろく利用され性能もますま ずだが、経験を積んだシステム・プログラマーでなければ 使いこなすのは大変であろう。 comp ・ Pて0t0C01S ・ ppp で は、間題を抱えたユーザーからの質間か絶えない。 さらに学びたい人のために Ⅵを Richard Stevens の『 TCP/IP lllustrated, Vol- urne 1 』 [ 2 ] では、シリアル接続での SLIP や PPP につい て論じている。彼の著書はどれもすはらしいが、この本は とくに優れている。 TCP/IP プロトコルの解説書は多い が、本書のようにプロトコル階層のさまざまなレベル、そ して実際に使われているシステムの細部まで述べたものは ない。彼は、視 : 勺アプローチを用いて TCP/IP の内部 に入り込み、プロトコルがどのように動くのか、あるいは どういう場合にうまく動かないのかを、受け取ったバケッ トがたどる j 斷呈を異なるマシンと OS て構築されたネット ワークを例に説明していく。 Craig Hunt の『 TCP/IP Network Administra- tion 』 [ 3 ] は、 PPP の情報とともに SLIP についてもき ちんと章を設け、 SunOS 用のフリーの SLIP や PPP の インストール、設定、使用法を説明している。ソフトウェ アに刊属の簡単な README ファイルよりも、はるかに 詳細な角犇見か載っていて役に立つ。 SLIP プロトコルとヘッダ圧縮は、 RFC1055 [ 4 ] と RFC1144 [ 5 ] で文書化されている。 ppp は、多くの RFC ( 1331 ~ 1334 、 1376 ~ 1378 、 1471 ~ 1474 、 1547 55

連載 / インターネットの禾と仕組みーの た、 proxy サーバーの活用です。 IANA (lnternet Assigned Numbers Authority) に レスが用意されています。これは RFC1597 に記述さ このために、閉じたインターネットのための IP アド きなけれはなりません。 イアウォール ) では両方のアドレス体系を混乱なく理解で 内線番号のように階層的ではないので、その境目 ( ファ 接外部とは通信できません。 つながるのは内部だけのように、ローカルアドレスでは直 ルなアドレスを使っていいのです。もちろん、内線番号で 内線電話番号と同しで、内部でだけ利用するときはローカ いネットワークにはこのような制約はありません。いわば これは外とつながるネットワークの場合で、つながらな 竹喋を担当しています 1 。 メーションセンター ) が世界の NIC と調整しながらこの ています。日本では、 JPNIC ( 日本ネットワークインフォ スは NIC (Network lnformation Center) で管理され ます。このようなユニーク性を確保するため、 IP アドレ 互に接続を得るにはそれぞオ功ゞ異なっている必要があり IP アドレスはホストを識別するためのものなので、相 ローカル IP アドレス 的がはっきりしています。 スクリーニングを併用するなどして、強化するにしても目 ストとしての設定をおこなえばいいわけで、ルータによる ります。外とつながるマシンにだけ、要寒 (Bastion) ホ 中継するガ去だと、セキュリティ管理の面でも利点があ より予約されたアドレスです 2 。 図 1 図 2 ローカルに使うことか保証されたアドレスの啝 ad dress 18a1 勝手なアドレスを使った場合 address 10Ca1 address appropnate same? 10 . 0 . 0 . 0 172 . 16.0.0 192 . 168.0.0 10 .255.255.255 172.31.255.255 192. 168.255.255 10.0.0.0 はクラス A 、 172.16.0.0 ~ 172.31.0.0 はク ラス B 、 192.168.0.0 ~ 192.168.255.0 はクラス C のア ドレスです。これらは連続したアドレスであり、それぞれ 10.0.0.0 / 8 、 172.16.0.0 / 12 、 192.168.0.0 / 16 というこ とになります。 1 ) 割当ては、インターネットとク月Æをおこなうときにネットワー ク・プロバイダから割当てを受けるのか現在ー - 」である。 : 恥ま「 JPNIC レポート」 1994 年 4 月号の、サーピス・プロバイダによる IP アドレス の割当て " を参具 2 : 恥ま「 JPNIC レポート」 1994 年 6 月号の、閉したインターネットの UNIX MAGAZINE 1995.4 たノ ) IP アドレス " を参 このアドレスを利用するメリットを、図 1 ~ 2 を例に簡 単に示します。区しになりますが、これらのアドレスは、 インターネットに存在しないことが IANA によってイ焉正 されています。 このアドレスは NIC からの割当てを受けることなく自 由に使えます。スペース的にも余裕があるので、自由なネ ットワーク構成が可能です。正規アドレスの利用にあたっ ては、限られた空間を有効に使うことカ球められますが、 このアドレスに関してはそういった要請はありません。 セキュリティ的にも有利で、インターネット上からもこ れらアドレスへの経路は存在しないので到達できません。 とくにネットワーク・プロバイダは、これらのアドレスが インターネット上べ充出しないように注意しています。 図 2 のように勝手なアドレスを使っている場合を考えて みましよう。これがほかの組織に割り当てられているアド レスと同しだとすると、ローカルなネットワークの経路を 設定した場合、インターネットて 1 司しアドレスを利用して いる組織への通信がまったくできなくなります。 、、閉したインターネットのためのアドレス " はインターネ ット上には存在しないので ( 図 1 ) 、インターネットと接続 する際にも、ローカルに利用しているアドレスク斈路情報 は、インターネットとの通信には景飛しません。 33

NET WORTH from UNIX REVIEW M. Steven Baker S 凵 P と PPP によるアクセス 職場での去も匠の流行語は、在宅勤務 (telecommuting) である。糸によれば、なんらかの形態で在宅菫莠に就い ている者は、労働人口の 11 % に上るという。従業員は通 勤時間の節約でゆとりをもてるし、経営者にとっては、生 産性カ舶止し、必要な物理空間を削減でき、社員がよく働 くことによって利朸ゞー E がる。ほかの組織と同様に、オレ ゴンり、 FI 政苻も在宅菫孵芳を孑している。当面の目標は、職 員が自宅からコンヒュータとネットワーク資源にアクセス する去を提供することにある。 こ数回にわたり、マルチメディアや、、ネットワーク " という川の念充ーーギガビット・ネットワークにおける実 験について述べてきた。そこで、今回はダイヤルアッフ。接 続というネットワークの緩流を調べてみよう。 一見したところ、リモートアクセスは簡単なことに思え る。ネットワークにモデムをつなぎさえすれはよい しかし、見かけにごまかされてはいけない。私の菫先に は、 MS-DOS マシンが NoveII ネットワークで、少数の Macintosh が EtherTalk で、 Sun WS が TCP/IP で、 それぞれネットワークに接続されている。はかの月ヨ政機 関には、さらに膨大で多種多様なコンピュータやネット ワークがある。 リモートアクセス用のハードウェアだけでなく、適切な ソフトウェアも必要だろう。ューザーが、使いやすい X べースの GUI アプリケーション (Sun の MailTool な ど ) や Macintosh 、 Windows プログラムに置れている場 合、リモートログインをさせるには何を提供すればよいの だろうか。ューサーは、自分の勤務先やドメインを越えて リモート接続 52 遠隔のインターネット資源を含むネットワーク資源にアク セスできるだろうか。在宅勤務者がネットワーク上では 1 つのノードにみえるようにし、会社にいるときとまったく 同様に各種の資源にアクセスできる竟を提供するのか理 想的である。 こ数年、同期 / 非同期の Point-to-Point 接続でネッ トワーク・データグラムを送るため、数多くのプロトコル カ甘是案されてきた。これらの多く (ThinWire 、 Reliable Asynchronous Transfer Protoc01 など ) は日の目を見 すに消えていったが、いくつかのガ去は業界標準になりつ つある。 現在、イのダイヤルアッフ甘妾続では UUCP 、 SLIP 、 PPP などのプロトコルか普及している。これらのうちも っとも古いのが UUCP (Unix-to-Unix CoPy) で、そ の歴史はベル研究戸励ゞ開発していた初期の UNIX まで遡 ることができる。 UUCP は、現在も電子メールや USE- NET ニュースの中幻幻こ幅広く利用されているバッチフロ トコルにもとづくフログラムである ( 本誌 1994 年 5 ~ 6 月号の本欄を参照 ) 。 SLIP や PPP を使うのは、シリアル回線で TCP/IP を利用するためであろう。歴史は SLIP (SeriaI Line lnternet Protocol) のほうが古いが、業界標準プロト コルとしては、インターネットで RFC (Request For Comments) プロセスを経て開発された多機能な PPP (Point-to-Point Protocol) が地歩を固めつつある。 PPP は機能が豊富で、 TCP/IP だけでなく、いくつか のネットワーク・プロトコル (IPX 、 AppIeTaIk など ) もサポートしている。しかし、 SLIP も依然各方面て利用 されている。 UNIX MAGAZINE 1995.4

連載 /NET WORTH— SLIP 機能に制限があるため、インターネット標準に提案された ていただけで、正式に文書化されたのは 1988 年である。 普及したが、プロトコルは C のソースコードで記述され SLIP は、 BerkeIey UNIX 、 Ultrix 、 SunOS を中心に TCP/IP ネットワーク接続をサポートするためだった。 ley UNIX の低速シリアル・インターフェイスによる SLIP が最初に開発されたのは 1984 年で、 Berke- ことはない。 UNIX MAGAZINE 1995.4 受信側でネゴシェーションをするための手段もない。この さらに、コネクションを制御するパラメータを送信側と 化できない。 線で、 IPX や AppIeTaIk などのプロトコルと IP を多重 ばら IP を扱うために言 t されたので、単一のシリアル回 スタックの一ヒ位層でおこなわねばならない。 SLIP はもっ にある。したがってエラー検出は、 TCP/IP プロトコル・ しないため、雑音の多い回線でエラーを検出できないこと SLIP の重大な欠点は、フレームのチェックサムを言 1 をもとにしている。 多くは、最初の BerkeIey SLIP と Jacobson の CSLIP 回っているフリー・ソフトウェアあるいは商用の SLIP の をおこなった ( のちに SunOS にも移植された ) 。現在出 幅な改良を施した CSLIP (Compressed SLIP) の開発 提案した。そして、 Berkeley UNIX 用として SLIP に大 縮する去 (PPP のオプションにも採用されている ) を Jacobson が、イシリアル回線で TCP/IP ヘッダを圧 1989 年になり、 Lawrence Berkeley Labs の Van として誤って解釈しないようにしている。 タとして扱われるバイトをネットワーク・バケットの終端 法によって、受信側の SLIP ソフトウェアが、本来デー ードは SLIP ESC (OxDB) 221 (OxDD) になる。この方 ESC (0xDB) 220 (0xDC) になり、 SLIP 工スケープコ めに使われる。バケット中の SLIP END コードは SLIP SLIP END やこのエスケープコード自体を律号化するた のエスケープコード (0xDB) は、バケット中に現れる グ・バイトである SLIP END (0xC0) を用いる。 SLIP で IP バケットの境界を示すために、特別なフレーミン SLIP の仕組みはごく単純である。一一連のバイト列中 ため、ヘッダのイ第の要不要や回線の両端にあるインター フェイスの IP アドレスは、 SLIP を利用する際になんら かのガ去で明示的に指定しなけれは・ならない。 UNIX では、一ヨ殳に SLIP や PPP をカーネルの一部 として実装する。 SLIP や PPP て接続した 2 台のコン ピュータは、ルーティングのためにお互いの IP アドレス を知る必喫がある。 通常、 Ethernet カードの IP アドレスは、 UNIX シ ステムのプート時やネットワーク・ソフトウェアの起重加 に設定される。 SLIP や PPP では、シリアル・インター フェイスの青勺な設定 (Ethernet のように 1 回だけ設定 する方式 ) ができないので、接続されているネットワーク に応じて重加勺に設定する仕組みが必要になる。このため、 UNIX カーネルを対話的に操作するコマンド行ユーティ リティを用意し、接続先のホストごとにシリアル・イン ターフェイスの IP アドレスを設定しなければならない。 UNIX のシリアルポートは、 SLIP や PPP だけでは なく、通常のログインにも利用される。 SLIP や PPP か らのログインと普通のユーサーを区別するため、 SLIP や PPP 用のログイン名やパスワードなどを用意する必要が ある。しかし、ターミナル・サーバーとそれに接続されて いるモデム群のせいで、なんらかの問題か起きたときに原 因を究明するのカ攤しい。 SLIP 自体は単純なのだが、通 信する 2 つのホスト間でネゴシェーションをする機構のた め SLIP て接続した際に発生する出題の解決は難しい。 こうした欠点はあるが、 SLIP はひろく利用されてい る。 IBM や SGI の WS には SLIP かオ票準で添付さ オ lnteractive UNIX (SunSoft) 、 SCO UNIX では、 ネットワーク機能追加パッケージとして販売されている。 いくつかの X86 用 SVR4 にも実装されている。商用の DOS/Windows 用 TCP/IP アプリケーションをはじ め、 NCSA Telnet や KA9Q TCP/IP クライアント、 MacTCP などの Macintosh 用製品が SLIP に対応して いる。さらに、ルータやターミナル・サーバーでも SLIP をサポートしているものが多い。 PPP は、上で述べたような SLIP の欠点を匱するた めに言 t された。 1989 年に PPP に関する最初の RFC PPP への転換 53