■ IP over ……

さて、ネット君。今回はIP over SFSSを説明する。

あいぴー、おーばー、えすえふえすえす。
えっと、まず、IP overなんちゃらってどういう意味ですか？

うむ、そうだな。例えば、「HTTPS」はHTTP over SSL、PPPoEはPPP over Ethernet、など「A over B」と書く場合は、「Bのプロトコルで、（カプセル化して）Aを運ぶ」という形になる。

SSLでHTTPを運ぶから、HTTPS。イーサネットでPPPを運ぶから、PPPoE？

そういうことだ。HTTPSはセキュアプロトコルであるSSLを使ってHTTPをやりとりする、という意味になる。あまり使わないが、通常のLANは言うならば、IP over Ethernetと言えるだろう。

ははぁ、ってことは、IP over SFSSは「SFSSというプロトコルで（カプセル化して）IPを運ぶ」ってことになるわけですね。

そういうことだ。IP over SFSSはRFC4824で定義されているIPデータグラムの転送の方法だ。▼ link

IPデータグラムの転送？ IP over EthernetがイーサネットでIPを運ぶ、ですから、IP over SFSSはあれですか、イーサネットとかと同じレイヤー2ですか？

レイヤー2というか、TCP/IPモデルのインターフェース層のプロトコル、ということになるな。まぁ、IPをカプセル化して運ぶ、イーサネットやPPPと同じ種類のプロトコルということになる。

なるほど。ってことはイーサネットやPPPの代わりに使うプロトコルってことになりますね。
で、博士？ SFSSってなんですか？

Semaphore Flag Signaling System、そうだな、日本語で言うならば手旗信号システムとでも翻訳するのがいいかな。

■ SFSSの基礎

IP over SFSSはSFSによるIPデータグラムの転送を行うプロトコルで、SFSSでIPを転送することをIP-SFSと記述する。

SFSってSFSSのSFSですか。

うむ、そこに気付くとはさすがネット君、やるな。

えへへへ。

褒めてねぇ。

はぅっ。

もちろん、SFSSのSemaphore Flag SignalingのSFSだ。IP-SFS、つまり手旗信号によるIP通信だな。SFS、手旗信号でIPデータグラムを転送する。SFSは1つの信号を指す。

信号。どんな信号なんですか？

一対の手持ちの旗を振る信号だな。信号の内容は後述だ。IP-SFSは、2つのインターフェース間でのリンクを形成する。リンクは光学的な半二重転送チャンネルを形成する。一般的には大気中で太陽光のもと有視界距離で行われる。

へぇ、半二重なんですね。イーサネットと同じですね。

そうだな、イーサネットも半二重だな。まぁ、図にするとこんな感じかな。

ふむふむ。双方のインターフェースが対面した形で、リンクになるんですね。

そうなる。対向のインターフェースのことはリンクパートナーと呼ぶ。あとはSFSSはポイントツーポイントリンクで、今現在のRFC4824ではユニキャストしか規定していない。

マルチキャストやブロードキャスト、エニーキャストはできないんですね。

■ 信号とフレームフォーマット

さて、1つの信号、つまりSFSは1ニブルになる。この単位で信号が転送されるわけだな。

にぶる？ 初耳な単位ですよ？

うむ、確かに聞きなれないな。1ニブルは4ビット。よって、2ニブル、2SFSで1オクテットが転送されることになる。さて、このSFSだが、アルファベットのA〜Yの25種類が存在する。

んん？ アルファベット25種類？ アルファベット以外伝達できないってことですか？
それにA〜Yまでだと、Zがないし。ASCIIで転送するにも、ASCIIは7ビットだし？

いや、そう難しく考えないでよい。A〜Pの文字に2進数0〜15を割り当てているということだ。たとえば、「AGH」という文字を送れば、それは16進数0x00、0x06、0x07を送ったということだ。

あぁなるほど……。なんでそんなことしてるんですか？「素直に0〜15までの数値を送る」ってことにすればいいじゃないですか？

それは国際標準の「セマフォア信号」という手旗信号に合わせてあるのだよ。セマフォア信号はアルファベットを手旗信号で定義しているからな。▼ link

国際標準。標準に合わせて。ん？でも25種類のSFSがあるんですよね？ 0〜15だと16種類ですが？

うむ、残りのQ〜Yまでの9種類は伝送制御信号だ。
ではまず、A〜Pの16種類、つまり16進数で0x00〜0x0Fを転送するSFS、データ信号のSFSだな。

あぁ、そうそう。これは受信側インターフェース側から見た信号だからな。

なるほど、このSFS1つで1ニブル、4ビットが転送できるわけですね。
あと制御信号もあるって。

うむ、伝送制御信号は次のように9種類がある。

Q〜Yの9種類ですね。最後のセマフォア信号でいうところのZとERRORは使わない、と。

さて、これで転送に使う信号が分かったところで、次はIP-SFSフレームの説明といこう。
IP-SFSフレームは、ヘッダ長4ニブル、ペイロード長0〜510ニブル、トレーラ長4ニブルだ。

ええ〜っと……。ヘッダが2オクテット、トレーラ2オクテット、と。んでペイロードが255オクテット、ですよね？
となるとフレームで、最小4オクテット、最大259オクテット、でいいのかな？

オクテットで換算するとそうなるな。フレームフォーマットは次のようになる。

あと、プロトコルとチェックサムタイプは次の通り。

あれ？ヘッダとトレーラって、5ニブルないですか？ さっき4ニブルだって言ってたのに。

あぁ、FSTやFENはイーサネットのプリアンプルと同じ扱いだから、フレーム長には含めないのだよ。

そっか、制御信号ですもんね。あとは上位プロトコルにチェックサムタイプに、フレームNo？
フラグメントするんですか？

うむ。さきほどネット君が換算したように、IP-SFSフレームはペイロードが255オクテットしかない。もしIPデータグラムが255オクテットを越えた場合、SFSSがフラグメントを行うわけだな。

そう言われればそうなりますね。まぁ、事前に最小MTU探索かなんかやっておけばフラグメントもおきないのか。

あとは、そうだな。転送速度だが、Spmはインターフェースの経験に依存する。

SFSsぱーみにっつ。単位時間が分なんですね。となると、bpsに直すと、SPM/60*4bpsになりますね。

■ コネクションとセッションの確立

さて、実際のIP-SFSの動作だが。インターフェースには送信、受信、待機の3つの状態がある。そして、動作はまずコネクションの確立から始める。

おぉ、ってことはコネクション型プロトコルなんですね。

そうだな。まず、コネクションの確立前にインターフェーススプーフィングを防ぐため、自己紹介をしておくことを推奨する。

いんたーふぇーすすぷーふぃんぐ？ スプーフィングってなりすましでしたっけ。ええっと、インターフェースのなりすましを防ぐために、自己紹介をする、と。

うむ。そして、コネクションの交渉をするわけだが。それは、インターフェースが同一サブネットの別IPアドレスを持っていることを確認し、タイムアウト時間を決定する。

タイムアウト時間。だいたいどれぐらいの値なんですか？

デフォルトは60秒だが、ま、煙草を一服したり、喉をうるおしたりできるぐらいの時間が目安だな。もし交渉が上手くいかない場合はデフォルト値を使用する。それに合わせ、キープアライブ間隔も決定する。自由に決めてよいが最低でもタイムアウト時間の5倍である必要がある。

デフォルト値を使った場合だとタイムアウト60秒、キープアライブ間隔300秒、ですか。

そうなるな。交渉が終わるとコネクションが確立される。コネクションの維持のため、キープアライブ間隔で制御信号KALをリンクパートナーに送信しなければならない。キープアライブ間隔の5倍の時間どのような信号もリンクパートナーから受け取らなければ、コネクションは切断されインターフェースは解散する。

キープアライブ間隔の5倍っていうと、デフォルトで1500秒ですね。

さぁ、コネクションが確立されたら、次はフレームの転送のためセッションを開始させる。

えっと、送信側が上位レイヤからIPデータグラムを受け取ると、Ready To Transmit、RTTを送って送信希望する？
それに対し、受信側もRTTだと、2〜TIMEOUT時間ランダムで待機……、あぁ、イーサネットで言うところのバックオフですね？

そうなるな。双方が送信を希望している、つまり衝突が発生したわけだから、バックオフするわけだ。

なるほど。で、受信側がRTRを返す、送信側がRTTと送信フレーム数を送る、受信側が返す、で送受信中に移行する、と。応答が返ってこない場合は待機に戻る？

そうだな、応答を返してくれない、RTRでない信号を送る、RTRの後に間違ったフレーム数を送る、などプロトコルに従っていない場合は、なんらかの手段を使うとよいだろう。

リンクパートナーの応答がなかったり、おかしかったら復元する、と。
えっと、コネクションとセッションの違いをもう少し詳しく。

あぁ、なんだ。確かに紛らわしいな。SFSSではコネクションの方が大きな単位だ。まず、リンクパートナーとコネクションを結ぶ。そうすると、待機状態になる。コネクションを確立したら、定期的にキープアライブをする。

キープアライブ間隔がデフォルトで300秒でしたっけ。それで、セッションは？

セッションは、IPデータグラムを1つ分やりとりする単位だな。うむ、確かにTCP/IPのコネクションとセッションの概念と逆だな。

TCP/IPだとセッションの方が大きい単位ですものね。SFSSだと、コネクションがあって、データグラムのやりとりで複数セッションが行われる、ですね。

■ IP-SFSフレームの転送

さて、セッションが開始されると、IP-SFSフレームを送信するわけだ。IP-SFSフレームはFSTからFENまで1フレーム、ということになる。受信側のリンクパートナーは1フレーム受信すると、ACKまたはNAKを応答する。

フレームごとに、確認応答するんですね。ACKの場合は正常受信できたから正常応答でいいですけど。NAKの時はどうするんですか？

NAKを受信、またはタイムアウトまでACK、NAKのどちらも受信しない場合は、送信側はIP-SFSフレームを再送する。4回再送が失敗した場合、セッションは切断され待機状態に戻らなければいけない。

4回再送が失敗ってことは、最初の1回入れて都合5回失敗したらってことですね。

そうなるな。さて、IP-SFSのフレームの転送と、SUN、FUNの動作を見てもらおうか。

FSTで始まり、FENで終わる。SUNがバックスペースで、FUNがフレームの再送信、ってところですか。

そうだ。あと、制御信号は取り消しできない。だから、SUNを2回連続して送ると、1回目のSUNの取り消しではなく、SUN2回分、という扱いになる。

なるほどなるほど。

では次は、受信側の動作を見てもらう。

ふむふむ。まず、SFSとSFSの間隔がタイムアウトを越えたら、フレームの再送信。タイムアウト2回分だったら、待機に戻る、と。

そうなる。あとは、受信側は任意のタイミングでFUNを送ることができる。それにより、フレームの再送をおこさせるわけだな。

へぇ〜。……、あれ？ 受信がはSUNを送ることはないんですか？

う〜む、何故か知らんが、受信側からのSUNの送信はプロトコル上規定されていないな。

■ インターフェースとセキュリティ

さて、インターフェースとセキュリティの話をしよう。まず、インターフェースだが、図では受信側、送信側とも1人ではあるが、インターフェースごとに最低2人を用意することを提案している。

んー、送信と受信で1人ずつのペアで、インターフェースを作る、って感じですか。

そうだな。転送量が多く長時間になるような場合には、代替のインターフェースを用意する必要があるな。
あとは帯域幅は変化しがちなので気をつけるように。時間とともに減少する。

なんとも不思議な伝送路ですね。帯域幅が変化するなんて。

まぁ、たしかに他にはみかけない特徴だな。
あとはそう、セキュリティだが。IP-SFSはセキュリティ的に安全ではない。有視界による光学的な転送なのでな。

あぁ、たしかに。リンク上に別のインターフェースがあったら、そのインタフェースも受信できちゃいますね。

そういうことだな。なのでIP-SFSでセキュアな通信をしたい場合には、上位のプロトコルでそれを実施する必要があるな。

上位のプロトコルでセキュア？ IPsecとか、SSL/TLSとか？

うむ。さて、他にIP-SFSでセキュリティに注意するところと言えば、インタフェースが送受信したデータを記憶することがある、という点だ。困ったことに、これの記憶の生存時間は決まっていないし、データがいつどこでインターフェースに出てくるかわからない。

はい？ インターフェースが送受信したデータを記憶しちゃうんですか？ そんなんありなんですか？

まぁ、あれだ。送受信のキューに入ったデータが、多少残るらしい。

ははぁ、それはそれは。しかも、あれですか、消えるかどうかもわからないし、いつ記憶されたデータが読みだされるかもわからない、とは随分困った仕様ですねぇ。

そうだな。インターフェースの記憶を削除する方法が現時点では、インターフェースの永久的な破壊ぐらいしかない。

破壊……、まぁ、しかたないのかもしれませんね。あまり長時間同じインターフェースを使わない方がいいってことなのかなぁ。

そうかもしれんな。では、今回はここまでとしよう。

はいなー。
３分間ネットワーキング・特別編でした〜♪