3 Minutes Networking
Extra No.3

3Minutes NetWorking

地獄極楽編

特別第3回IP over SFSS

■ 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つのインターフェース間でのリンクを形成する。リンクは光学的な半二重転送チャンネルを形成する。一般的には大気中で太陽光のもと有視界距離で行われる。

ネット助手

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

インター博士

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

インターフェースとリンク

[FigureEX03-01:インターフェースとリンク]

ネット助手

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

インター博士

そうなる。対向のインターフェースのことはリンクパートナーと呼ぶ。あとは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だな。

SFSセマフォア信号16進数2進数
AA0x000000
BB0x010001
CC0x020010
DD0x030011
EE0x040100
FF0x050101
GG0x060110
HH0x070111
II0x081000
JJ0x091001
KK0x0A1010
LL0x0B1011
MM0x0C1100
NN0x0D1101
OO0x0E1110
PP0x0F1111

[TableEX03-01:SFS データ信号]

インター博士

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

ネット助手

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

インター博士

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

SFSセマフォア信号制御信号意味
QQFSTFrame STart
RRFENFrame ENd
SSSUNSignal UNdo
TTFUNFrame UNdo
UUACKframe ACK
VVKALKeepALive
WWNAKframe No AcK
XXRTRReady To Receive
YYRTTReady To Transmit
ZZunused---
ERRORunused---

[TableEX03-02:SFS 伝送制御信号]

ネット助手

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

インター博士

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

ネット助手

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

インター博士

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

SFS数フィールド意味
1FSTフレームの開始
1プロトコル上位プロトコル
1チェックサムタイプチェックサムに使用するアルゴリズム
2フレームNoIPデータグラムをフラグメント化した際のフレーム番号
0〜510データペイロード
4CRCCRCチェックサム
1FENフレームの終了

[TableEX03-03:IP-SFS フレームフォーマット]

インター博士

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

  • プロトコル
    • 0 … なし
    • 1 … IPv4
    • 2 … IPv6
    • 3 … IPv4(gzip圧縮)
    • 4 … IPv6(gzip圧縮)
    • 5〜15 … 拡張用の予備
  • チェックサムタイプ
    • 0 … なし
    • 1 … CCITT CRC 16
    • 2〜15 … 拡張用の予備
ネット助手

あれ?ヘッダとトレーラって、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秒ですね。

インター博士

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

[FigureEX03-02:IP-SFSセッションの開始]

ネット助手

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

インター博士

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

ネット助手

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

インター博士

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

[FigureEX03-03:セッションの復元]

ネット助手

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

インター博士

あぁ、なんだ。確かに紛らわしいな。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の動作を見てもらおうか。

[FigureEX03-04:IP-SFSフレームの転送]

ネット助手

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

インター博士

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

ネット助手

なるほどなるほど。

インター博士

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

[FigureEX03-05:IP-SFSフレームの受信]

ネット助手

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

インター博士

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

ネット助手

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

インター博士

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

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

インター博士

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

ネット助手

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

インター博士

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

ネット助手

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

インター博士

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

ネット助手

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

インター博士

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

ネット助手

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

インター博士

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

ネット助手

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

インター博士

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

ネット助手

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

インター博士

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

ネット助手

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

インター博士

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

ネット助手

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

RFC4824
2007年、4月1日発表。
ニブル
[nibble]
セマフォア信号
[semaphore signal]
参考リンクのwikipediaを参照。
Spm
[SFSs per minutes]
ネット助手ネット君の今日のポイント
  • さすがにこれを実行しているのは見つけられませんでした

3 Minutes NetWorking Extra No.3

管理人:aji-ssz(at)selene.is.dream.jp