要約

  • SCHClet の現行 Internet-Draft は、一つの Stratum と一つの Instance に限定した自己完結型の SCHC 機能を提案し、ルール管理や暗黙にできるヘッダーを省けるようにする。
  • 省略による意味は SCHClet Configuration に移る。相互運用を証明するには、RuleID の一致だけでなく、両端の設定、非一致入力の処理、復元結果、上位層の成否までを確認する必要がある。

処理は短く、分岐も少なく、昨日まで正しく動いていた。ところが対向装置だけが新しいルール集合に変わった瞬間、同じ一バイトが別の前提を指す。小さな関数の美しさは失われていない。失われたのは、二つの関数が同じ世界を見ているという条件である。

2026年9月29日付の SCHClet ドラフト第01版 は、この条件を設計の中心に置く。文書は SCHC ワーキンググループの現役 Internet-Draft で、Standards Track を目指している。RFC でも、実装報告でも、導入実績でもない。提案は、一つの SCHC サブ機能または機能の一部を、一つの Stratum と一つの SCHC Instance だけで動く部品として切り出すことだ。

SCHClet は圧縮だけ、特定の断片化モードだけ、限定した演算子や固定パラメーターだけを実装できる。ルール管理を持たず、ルールを読み取り専用にすることもできる。一般的な枠組みを抱えないため、コード、メモリー、処理量、消費電力を減らせる可能性がある。ドラフトが示すのは設計上の期待であり、あらゆる実装での削減量を測ったベンチマークではない。

最小圧縮例では、IPv6 の Version、Traffic Class、Flow Label を 6、0、0 と固定する。四バイト分の情報を八ビットの RuleID に置き換え、0x60 と 0xFF を使う。ビット効率だけを見れば贅沢だが、ドラフトはコードを単純にするため意図的にそうしたと説明する。通信量を極限まで削るのではなく、実装の予測可能性を買う設計である。

固定値は消滅したのではない。両端が持つ設定へ移った。SCHC アーキテクチャのドラフトは Stratum、Instance、Discriminator を区別する。対象が一組に限定される SCHClet では、そのヘッダー全体を省略できる。受信側が欠けた文脈を既に知っているからだ。対向だけが変われば、短いパケットには相違を説明する材料が残っていないかもしれない。

そこでドラフトは、SCHClet を規定する文書に対応する SCHClet Configuration の定義を求める。また、完全な SCHC 実装が相互運用を必須とされるのは、対応する設定を持つ場合である。「完全」という形容は万能の互換証明ではない。RuleID の幅、ルール集合、Target Value、Matching Operator、CDA、断片化方式、タイマー、未知入力の扱いが一致して初めて、同じ互換集合に入る。

例は、将来あり得る全ビット1のパターンを扱わない。入力が IPv6 に限られるなら問題にならないかもしれない、と文書は述べる。だが入力が本当に IPv6 だけかどうかは、関数単体ではなく運用境界の性質である。どのルールにも一致しない入力は、設定に従って安全に拒否するか、そのまま渡さなければならない。そのまま渡す場合も、次段が未圧縮入力を識別し、正しく受け入れることが前提になる。

RFC 8724 で SCHC は既に共有コンテキストとルールに依存している。RFC 9011 は特定環境のプロファイルが選択肢を固定する例であり、RFC 9441 はオプション機能が後から発展し得ることを示す。SCHClet はその文脈依存をなくすのではなく、狭い実行部品として持ち運べるようにする。部品が小さいほど、意味を与える設定の同一性が重要になる。

したがって運用上の受領証は、RuleID を読めたという記録では足りない。正確なドラフトまたはプロファイル版とローカルビルドを特定し、設定とそのハッシュ、所有者を固定する。両端が同じ集合をどのように配布または交渉したかを示し、選ばれたルールか非一致経路、圧縮・断片化結果、対向の解釈、約束した範囲での復元一致を観測する。最後に上位層の構文解析、セキュリティー検証、アプリケーション結果を確かめる。

すべての SCHClet に中央管理や動的交渉が必要という意味ではない。変更しない二台なら工場設定が最適な場合もある。限定された運用領域では二者間手順で十分かもしれない。ただし、どの方法を選んでも、それはパケットから省いた合意を維持する以上、実務上はプロトコルの一部である。

Lu Heng が述べる最小共通仕様は、相互運用に必要な部分だけを共有し、残りの局所的な選択を守る考え方だ。SCHClet はその発想に忠実である。同時に、局所化された部分に名前と責任が必要だと示す。動くコードは、同じ設定を受け入れる相手と出会い、期待したサービス結果を返して初めて証拠になる。

情報源