おはようございます！
GMOコネクトでCTOしている菅野（かんの）こと、さとかん です。
皆さん、さっきぶりです。
※ 記事を読んでくれている人、ありがとうございます。
はじめに
2025年11月1日から2日にかけてモントリオールで開催されたIETF 124 Hackathon参加レポート3部作の最終回となる本記事では、AI/LLMの活用、DNS/アプリケーションプロトコル、IoT/インネットワークコンピューティングの最新プロジェクトを紹介します。
今回のハッカソンでは、30以上のプロジェクトが成果を発表し、実装と相互運用性テストを通じて、IETFの標準化活動を推進しました。
本記事で紹介するプロジェクト
- 本記事では、AI/LLM活用プロジェクトとして、LLM-Powered eBPFを実現するPacketScopeと、データおよびエージェント認識型の推論・トレーニングネットワークを構築するAI-network（DA-ITN）を取り上げます。
- DNS/アプリケーション分野では、DNS over CoAPのUnboundへの実装、dry-run DNSSECの実装、深層強化学習を用いたMulti-CDNの最適化、会話データコンテナプロトコルvCon、IPv6 Web Resource Checker、そしてDNS関連の各種プロジェクト（DELEG、DNS Transport Signaling、BIND/QUICなど）を紹介します。
- さらに、IoT/インネットワークコンピューティング分野では、ロボットカーでの衝突回避を実現したI2ICF Project、5GネットワークにI2NSFフレームワークを統合した5G-I2NSF、そしてSCHC Management（CORECONF）を取り上げます。
- 最後に、個人的に注目しているプロジェクトとして、ハイスループット暗号Rocca-Sにまとめて、あと量子ネットワーク仕様策定を目指すQUANTUMについても解説します。
1. AI/LLM活用プロジェクト
1.1 PacketScope: LLM-Powered eBPF
プロジェクト概要
LLM（大規模言語モデル）とeBPF (XDP) を統合した、「プロトコルスタック防御のためのインテリジェント防御ループ」の構築に取り組みました。
主な達成事項
まず、自動脅威検出と対応の仕組みを構築しました。eBPFがカーネル空間でパケットをキャプチャし、ゼロレイテンシーでトラフィック統計を収集します。LLMが収集されたデータ（パケット数、送信元IP分布、プロトコル分布など）から異常なパターンを分析し、脅威を検出すると、その特徴（送信元IP、プロトコル、パケット特性など）に基づいてeBPFフィルタリングルールを自動生成します。例えば、ICMP Flooding検出時には、疑わしいIPアドレスからのICMPパケットをドロップするeBPFコードを生成します。
次に、動的フィルタリングを実現しました。生成されたeBPFコードをカーネルのXDPフックにホットスワップすることで、カーネル再コンパイルや再起動不要で、リアルタイムにフィルタリングルールを更新できます。
実証実験では、ICMP Flooding攻撃を実際に実行し、LLMが異常なICMPトラフィックパターン（短時間での大量ICMPリクエスト）を検出することを確認しました。自動生成されたeBPFルールにより、攻撃トラフィックをブロックし、攻撃検出から防御まで数ミリ秒で完了しました。
技術的なポイント
eBPF/XDPは、カーネル内で安全にプログラムを実行できる技術で、ネットワークドライバーレベルでのパケット処理により超低レイテンシーを実現します。
このアプローチは、セキュリティにおけるパラダイムシフトをもたらします。「LLM + eBPF」の組み合わせにより、セキュリティが従来の「受動的な応答」から「インテリジェントでリアルタイムなブロック」へ、そして「事後対応」から「予測的防御」へと移行します。
関連リンク
1.2 AI-network: Data and Agent Aware Inference and Training Network (DA-ITN)
プロジェクト概要
トレーニング、推論、エージェント運用を含むAIサービスを促進するための、AIネットワークの構築を目指しました。
アーキテクチャ
AIネットワークは4層で構成されています。最上層のインテリジェンス層がAI最適化と学習/推論制御を担当し、制御プレーンがリソース管理とスケジューリングを行います。データプレーンはデータ転送とフロー制御を担い、OAM層が運用・管理・保守を支援します。
PoC実装
分散トレーニングの最適化に焦点を当てました。ネットワーク内の多数のノードにデータセットが分散されている環境で、特定のAIモデルのトレーニングに最適なデータのサブセットを選択するため、NWOTアルゴリズム（Network-Aware Optimal Transport）を考案・テストしました。
NWOTアルゴリズムは以下のように動作します。まず、各ノードが保持するデータの品質を評価し、モデルの精度向上への寄与度を推定します。次に、各ノードからトレーニングノードへのデータ転送コストを計算し、帯域幅、レイテンシ、経路の混雑度を考慮します。そして、モデル精度を最大化しつつ、総転送コストを予算内に抑える最適なデータ選択を計算します。最後に、特定のノードに偏らないよう、データの多様性を制約条件として追加します。
この手法により、無駄なデータ転送を削減しながら、効果的なモデルトレーニングを実現します。
今後の展望
今後は、他のエージェントプロトコルとの統合が課題として挙げられています。具体的には、A2A（Agent-to-Agent）、MCP（Model Context Protocol）、ANP（Agent Negotiation Protocol）といったプロトコルとの相互運用性をサポートする予定です。
期待される応用分野として、Federated Learning（連合学習）、Edge AI、Multi-Agent Systemsなどが挙げられます。
2. DNS/アプリケーションプロトコル
2.1 DNS over CoAP (DoC) deployment in Unbound
プロジェクト概要
DNS over CoAP (DoC) のUnboundへのポーティング作業が継続されました。
CoAP（Constrained Application Protocol）とは
CoAPは、IoTデバイス向けに設計されたリソース制約のあるデバイスに最適な軽量プロトコルです。UDPベースで動作し、HTTPライクなRESTfulインターフェースを提供します。
なぜDNS over CoAP？
DNS over CoAP（DoC）にOSCOREを組み合わせることで、複数のメリットが得られます。CoAPのバイナリフォーマットによりコンパクトな通信が可能で、OSCOREによる暗号化でセキュアな通信を実現し、UDPベースの低オーバーヘッドにより効率的な通信ができます。
主な達成事項
設定の柔軟化として、OSCOREクレデンシャルの設定を非定数化し、CoAPリソースパスの設定可能化を実現しました。また、DTLS統合では、DTLSのためにTLS-PKIの再利用を完了し、既存のTLS証明書基盤を活用できるようにしました。
残された課題
libcoapのバグとして、ピギーバックされたACKメッセージではなく、空のACKのみを送信する問題があり、現在原因を究明中です。
技術的背景として、CoAPでは、レスポンスをACKにピギーバック（相乗り）させることで、メッセージ数を削減できます。
**通常の動作（4メッセージ）**では、クライアントがサーバーにCON（確認要求）でリクエストを送信し、サーバーが空のACKを返し、その後サーバーがCONでレスポンスを送信し、最後にクライアントがACKを返します。
一方、ピギーバック動作（2メッセージ） では、クライアントがサーバーにCONでリクエストを送信し、サーバーがACKにレスポンスをピギーバックして返すだけで完了します。
ピギーバックにより、メッセージ数が半減し、レイテンシと電力消費が削減されます。これはIoTデバイスにとって重要な最適化です。
2.2 dry-run DNSSEC
プロジェクト概要
draft-yorgos-dnsop-dry-run-dnssec-04に基づき、Unboundへのdry-run DNSSECの実装に着手しました。
dry-run DNSSECとは？
dry-run DNSSECは、DNSSEC導入前のテストを行い、本番環境への影響なしで動作確認を行うことで、段階的な移行を支援することを目的としています。
実装内容
設定されたdry-run DNSSECトラストアンカーについて、DNSSEC鍵エラーを検出します。エラー時の動作として、DNSエラーレポートを監視サーバーへ送信し、同時に非セキュアな回答に戻ることで、サービスを継続します。
ユースケース
DNSSECの段階的導入のプロセスを説明します。
Phase 1: Monitoring（監視フェーズ） では、dry-runモードでDNSSECを有効化します。DNSSEC検証エラーが発生しても、ユーザーへのサービスは継続し、すべてのDNSSEC検証エラーをログに記録して監視サーバーに報告します。運用チームがエラーの原因を分析し、鍵のロールオーバー失敗、署名の期限切れ、設定ミスなどを特定します。
Phase 2: Testing（テストフェーズ） では、問題が少ないゾーンから本番DNSSECを有効化し、他のゾーンはdry-runモードを継続します。本番環境とdry-run環境を並行運用し、差異を分析します。
Phase 3: Production（本番フェーズ） では、すべてのゾーンで本番DNSSECを有効化し、dry-runモードを無効化して、完全なDNSSEC保護を実現します。
この段階的アプローチにより、DNSSEC導入時のリスクを最小化し、問題が発生しても即座にロールバックできます。
2.3 Multi-CDN
プロジェクト概要
クライアントにとってリアルタイムで最適なCDNを動的に選択する、DRL（深層強化学習）ソリューションの開発と、それをdash.jsへの統合が行われました。
主な達成事項
dash.js GUIの強化として、CDNごとのリアルタイムスループット表示、RTTの可視化、ストール追跡機能を実装しました。また、リアルタイム予測機能として、CDNの状態を予測し、将来の品質を予測してproactiveに切り替える機能を実装しました。
DRL（深層強化学習）ベースのアプローチ
エージェントの動作について説明します。エージェントは状態として各CDNのスループット、RTT、過去のスタール（再生停止）履歴を観測します。行動として、次のビデオセグメントをどのCDNから取得するかを選択します。報酬として、QoE（Quality of Experience）の向上度合い（高画質、低スタール、安定性など）を評価します。
学習プロセスは以下のように進行します。初期状態では、エージェントは各CDNの性能データを収集します。CDN選択時には、現在の状態に基づいて、Q値（期待される累積報酬）が最も高いCDNを選択します。結果観測では、選択したCDNからビデオセグメントをダウンロードし、スループット、遅延、スタールの有無を記録します。報酬計算では、QoEメトリクス（ビットレート、スタール回数、ビットレート変動など）に基づいて報酬を計算します。最後に学習更新として、Q値を更新し、次回の選択に活かします。
このプロセスを繰り返すことで、エージェントは各CDNの特性を学習し、状況に応じた最適な選択ができるようになります。
発見された課題
ローカル最適化の限界が明らかになりました。純粋にローカルな（単一クライアントの）最適化では、グローバルな効率性が達成されず、全クライアントが同じCDNに殺到する問題が発生します。この課題は、個々のクライアントが自己最適化を追求することで、システム全体のQoE（Quality of Experience）が低下する典型的な例です。
今後の展望
マルチエージェントDRLの導入を検討しています。複数のクライアントエージェントが協調し、グローバルなQoEトレードオフをバランスすることで、この問題の解決を目指します。
2.4 vCon: conversational data container
プロジェクト概要
会話データコンテナプロトコルvCon（draft-vcon-vcon-core）に関して、transferタイプDialog ObjectとSIP Session IDの利用実装と探求が目標でした。
vConとは？
vCon（virtual Conversation） は、会話データ（通話、チャット等）を標準化されたコンテナに格納し、メタデータとコンテンツを統合し、プライバシー保護機能を提供します。
主な用途として、コンタクトセンター、コンプライアンス記録、会話分析などが挙げられます。
主な達成事項
"transfer"タイプのDialog Object実装として、ブラインド転送（Blind Transfer）のサポートとコンサルタティブ転送（Consultative Transfer）のサポートを実現しました。また、NetSapiens統合として、NetSapiens Call Center Platformとの統合を行い、SIPベースの転送を含むvConの生成・テストを実施しました。
発見された課題
メタデータの欠如という課題が浮上しました。コンサルタティブコールが録音されていない場合、転送に関するメタデータが存在せず、どのように転送をマークするかという問題があります。
具体的な問題について説明します。vConは会話データを構造化して格納しますが、以下のような課題が浮上しました。
ブラインド転送の記録では、エージェントAが顧客と通話中、エージェントBに直接転送する場合、転送元エージェント（A）、転送先エージェント（B）、転送時刻は記録可能ですが、転送理由や顧客の同意などの追加メタデータをどう扱うかという問題があります。
コンサルタティブ転送の記録では、エージェントAが顧客と通話中、エージェントBに事前相談してから転送する場合、理想的には、A-B間の相談内容も記録したいところですが、相談通話が録音されていない場合、メタデータのみで転送を表現する必要があります。どのような最小限のメタデータが必要か（転送タイプ、理由コード、タイムスタンプなど）、そして転送シーケンス全体をどう表現するかという課題があります。
プライバシーとのバランスも重要です。詳細なメタデータは監査やコンプライアンスに有用ですが、過度に詳細だとプライバシーの懸念があります。適切な粒度の検討が必要です。
これらの課題について、実装経験を通じて仕様の改善案が議論されました。特に、コールセンター環境での実際のユースケースに基づいて、最小限かつ効果的なメタデータセットを定義する必要性が認識されました。
2.5 IPv6 Web Resource Checker
プロジェクト概要
ウェブアプリケーションがIPv6オンリークライアント環境で動作するかどうかを検証する、Seleniumベースのテストサービスに関する作業が行われました。
背景
IPv6移行の課題として、多くのウェブサイトはIPv4/IPv6デュアルスタックですが、外部リソース（画像、CSS、JS等）がIPv4オンリーの場合があります。IPv6オンリー環境では一部のコンテンツが表示されない問題が発生します。
特に、ウェブアプリケーションは多くのソースからリソースを動的に使用するため、単純な静的解析では検出できないIPv4依存性が存在します。JavaScriptによる遅延ロードや、サードパーティスクリプトが追加で読み込むリソースなど、実際のブラウザ環境でしか検出できない問題があります。
解決策
実ブラウザでのテストを採用しました。Seleniumを使用し、IPv6オンリーネットワークで実行し、すべてのリソースリクエストを監視します。JavaScriptで動的にロードされるリソースも検出できます。このアプローチにより、真のウェブブラウザを使用した包括的な検証が可能になります。
主な達成事項
サービスのリリースとして、IETF 124の数日前にサービスを公開し、ハッカソン中にフィードバックを受けて改善しました。検出機能として、IPv4オンリーのリソースを特定し、動的にロードされるコンテンツもカバーし、スクリーンショットで視覚的に確認できるようにしました。
詳細な検出プロセスについて説明します。
テスト実行では、ユーザーがテスト対象のURLを入力します。IPv6オンリー環境でのブラウザ起動では、Seleniumがヘッドレスブラウザ（ChromeまたはFirefox）をIPv6オンリーネットワークで起動します。ページロードでは、ブラウザがターゲットURLを開きます。
リソース監視では、すべてのHTTPリクエスト（HTML、CSS、JavaScript、画像、フォント、APIコールなど）を記録し、各リクエストのIPアドレスを記録（IPv4 vs IPv6）します。動的に生成されるリクエスト（JavaScriptによる遅延ロードなど）も捕捉します。
エラー検出では、IPv4オンリーのリソースへのアクセスが失敗した場合、そのURLとIPアドレスを記録します。スクリーンショットでは、ページの最終的な表示状態をキャプチャし、欠けているリソースを視覚的に確認できます。
レポート生成では、問題のあるリソース一覧（URL、IPv4アドレス、リソースタイプ）、全リソース数とIPv4オンリーリソースの割合、推奨事項（CDNの使用、IPv6対応など）を提供します。
このツールにより、開発者は実際のユーザーが経験する問題を事前に発見できます。
関連リンク
2.6 DNS Miscellaneous Projects
プロジェクト概要
DNS分野でいくつかの注目すべきプロジェクトが並行して実施されました。これらは、DNSプロトコルの拡張、セキュリティ強化、そして新しいトランスポート層の実装など、DNSエコシステムの様々な側面をカバーしています。
主なプロジェクト
DELEG（DNS委任の拡張）: 新しい拡張可能なDNS委任プロトコルDELEGの実装作業が進められました。DELEGは、従来のNSレコードベースの委任機構を置き換え、より柔軟で拡張性の高い委任を実現することを目指しています。
DNS Transport Signaling: DNSトランスポートシグナリングの実装作業が行われました。これにより、クライアントとサーバー間でトランスポート層の能力や設定をネゴシエートすることが可能になります。
BIND/QUIC統合: ISC BIND向けにlibuvとOpenSSL QUICを統合するPoC（概念実証）が開発されました。これは、DNS over QUIC（DoQ）のBINDサポートに向けた重要な一歩です。QUICの低遅延と接続マイグレーション機能により、モバイル環境でのDNSクエリの信頼性が向上することが期待されます。
Poisonlicious: DNSリゾルバーキャッシュ共有プロトコルのISC BIND向け実装が進められました。このプロトコルは、複数のリゾルバー間でキャッシュ情報を効率的に共有し、全体的なクエリ応答時間を短縮することを目的としています。
PQC DNSSEC: ポスト量子暗号（PQC）のDNSSECテストベッドの構築が行われました。特に、ML-DSA（Module-Lattice Digital Signature Algorithm）署名アルゴリズムのMLT（Merkle Tree Ladder）モードサポートの予備的な作業が実施されました。MLTモードは、署名サイズを削減しながら、量子コンピュータに対する耐性を維持する技術です。
技術的意義
これらのプロジェクトは、DNSの将来を形作る重要な取り組みです。QUICの統合により、DNSはより高速で信頼性の高いトランスポートを獲得し、PQC DNSSECにより、量子コンピュータ時代においてもDNSのセキュリティが保証されます。また、DELEGやTransport Signalingは、DNSプロトコル自体の柔軟性と拡張性を高め、将来の要求に対応可能なアーキテクチャを提供します。
3. IoT/インネットワークコンピューティング
3.1 Interface to In-Network Computing Functions (I2ICF) Project
プロジェクト概要
I2ICFフレームワークを移動体（ロボットカー）向けに拡張し、インテントベースの衝突回避を実現しました。
実装内容
ロボットカーでの衝突回避について説明します。
センサーフュージョンでは、カメラとLiDARのデータをリアルタイムで融合し、物体までの距離を正確に測定します。リアルタイム処理パイプラインでは、センシング、認識、判断、制御という流れをミリ秒単位で実現します。自動停止機能では、障害物が近づきすぎると自動的に停止し、安全距離の動的調整を行います。
デモンストレーション結果
反応時間は50ms以下、停止精度は±2cm、誤検出はテスト期間中0%という優れた結果を達成しました。
デモシナリオの詳細について説明します。
センサーフュージョンでは、カメラが前方の映像をキャプチャ（30fps）し、LiDARが距離データを取得（10Hz）します。両センサーのデータをタイムスタンプで同期し、融合します。
物体検出と距離測定では、カメラ映像から物体を検出（YOLO等の物体検出アルゴリズム）し、LiDARデータから物体までの正確な距離を測定します。カメラとLiDARのデータを統合し、物体の位置と距離を3次元で把握します。
リアルタイム判断では、障害物までの距離が安全閾値（例：1.5m）を下回るかチェックし、ロボットカーの現在速度を考慮した停止距離を計算します。衝突リスクを評価し、これを50ms以内に完了します。
自動停止では、衝突リスクが高いと判断した場合、即座にモーター制御指令を送信し、ブレーキを作動させ、目標位置の±2cm以内で停止します。
このリアルタイム処理により、人間の反応時間（約200-300ms）を大幅に上回る安全性を実現しています。
今後の計画
今後の計画として、インテントトランスレータの設計・実装により、高レベルな意図を具体的なポリシーに変換します。ポリシートランスレータの実装により、ポリシーをネットワーク機能に展開します。テストベッドの拡張では、複数台のロボットカーでの協調動作、V2V（Vehicle-to-Vehicle）通信、推論データの共有を実現します。
関連リンク
3.2 5G-I2NSF: An Integrated Security System for 5G Networks with I2NSF
プロジェクト概要
I2NSFフレームワークを5Gネットワークに統合し、Edgeベースのアプローチでセキュリティポリシーのプロビジョニングを行いました。
従来のアプローチの課題
従来のクラウドベースのセキュリティでは、セキュリティ機能がクラウドに配置されるため、すべてのトラフィックをクラウドまで送信する必要がありました。これにより高レイテンシが発生し、5Gの低遅延というメリットを損なっていました。
提案アプローチ
UPF内部へのNSF配置により、低レイテンシなセキュリティサービスを提供します。
主な達成事項
UPF内部でのNSF（ファイアウォール）生成について説明します。ユーザー機器（UE）が5Gネットワークに接続する際、I2NSFコントローラーが自動的にUPF内部にファイアウォールインスタンスを生成します。UE固有のセキュリティポリシーを適用し、許可するプロトコル、ポート、レート制限、アプリケーション識別などを設定します。
UEハンドオーバー時のポリシー移行について説明します。UEが基地局間を移動（ハンドオーバー）すると、5Gコアネットワークが新しいUPFを割り当てます。I2NSFコントローラーは以下の手順でポリシーを移行します。まず、現在のUPF（UPF 1）からUEのセキュリティポリシーを取得します。次に、新しいUPF（UPF 2）にNSFインスタンスを生成します。そして、取得したポリシーを新しいNSFに適用します。最後に、UEのトラフィックを新しいUPFに切り替えます。この一連のプロセスが100ミリ秒以内に完了し、UEは中断なくサービス継続できます。
実装されたNSF機能
ファイアウォールとして以下の機能を実装しました。パケットフィルタリングでは、送信元/宛先IP、プロトコル、ポート番号によるフィルタリングを行います。レート制限では、アプリケーションごとの帯域制限（例：ビデオストリーミングを10Mbpsに制限）を実現します。DDoS対策では、異常なトラフィックパターンの検出とブロックを行います。アプリケーション識別では、ディープパケットインスペクションによるアプリケーション識別とポリシー適用を実現します。
例えば、以下のようなポリシーを設定可能です。優先度1では、HTTPSトラフィック（ポート443）を許可します。優先度2では、動画ストリーミングを10Mbpsにレート制限します。優先度3では、脅威インテリジェンスで特定された悪意のあるIPサブネットからの通信をブロックします。
5G + エッジセキュリティのメリット
5GとエッジセキュリティをCombinationすることで、複数のメリットが得られます。ユーザーに近い場所で処理することで超低遅延を実現し、複数のUPFに分散することでスケーラビリティを確保し、UEごとにカスタマイズされたセキュリティにより柔軟な対応が可能になります。
ユースケース
このシステムは様々な分野で活用できます。産業IoTでは工場内のロボットやセンサーの保護に、自動運転ではV2X通信のセキュリティに、スマートシティでは大量のIoTデバイスの管理に利用できます。
関連リンク
3.3 SCHC Management (CORECONF)
プロジェクト概要
SCHC（Static Context Header Compression）エンドポイント内にCORECONFインターフェースを統合しました。
SCHCとは？
SCHCは、IoTデバイス向けのヘッダー圧縮技術です。IPv6/UDPヘッダーを数バイトに圧縮することで高い圧縮率を実現し、大きなパケットを小さなフレームに分割するフラグメンテーション機能を持ちます。LoRaWAN、NB-IoT、Sigfoxなどの低電力広域ネットワークで利用されています。
プロジェクトの目的
動的なSCHCルール管理の実現を目指しました。固定されたSCHCルールではなく、ネットワーク状況やトラフィックパターンに応じて動的に変更可能にすることが目標です。
実装内容
CORECONFインターフェースの統合として、SCHCエンドポイントにCORECONFサーバーを実装し、リモートからのSCHCコンテキスト操作が可能になりました。
サポートする操作として、FETCHによるコンテキストの取得、iPATCHによるコンテキストの部分更新、POST (RPC)によるリモートプロシージャコールを実装しました。
動的最適化のデモとして、進行中のトラフィックに適応して、圧縮ルールをオンザフライで最適化する機能を実証しました。
動作シナリオの例について説明します。
初期状態では、IoTデバイスが温度センサーデータを定期的に送信し、SCHCは温度データ用の圧縮ルールを適用し、圧縮率70%を達成しています。
トラフィックパターン変化では、デバイスが温度と湿度の両方のデータを送信し始めます。
管理サーバーの分析では、CORECONFのFETCH操作で現在のSCHCコンテキストを取得し、新しいトラフィックパターンを分析し、温度+湿度データに最適化された新しい圧縮ルールを計算します。
ルールの更新では、CORECONFのiPATCH操作で、既存のルールを部分的に更新し、デバイスに新ルールを送信します。
結果として、圧縮率が70%から85%に向上し、ペイロードサイズが30バイトから15バイトに削減されます。
このプロセス全体が、トラフィックを中断することなく実行されます。
実証された価値
トラフィックの多様性に対応し、ネットワーク負荷を削減し、データ送信量の削減によるバッテリー寿命延長を実現しました。
4. その他の注目プロジェクト
4.1 Rocca-S in parallel mode
プロジェクト概要
256ビット対称鍵暗号アルゴリズムRocca-Sの性能向上を目指し、AVX-512命令セットを使用して並列モード（Rocca-SX2, Rocca-SX4） を実装しました。
パフォーマンス結果
テスト環境: AMD Ryzen 9 9900X
| バージョン | スループット |
|---|---|
| Rocca-S (標準) | 238.92 Gbps |
| Rocca-SX2 (2並列) | 477.84 Gbps |
| Rocca-SX4 (4並列) | 955.68 Gbps |
比較: AES-GCMの約8倍の速度を実現しました。
並列化の仕組み
AVX-512命令セットを使用して、複数のデータストリームを同時に暗号化することで、スループットを大幅に向上させました。
Rocca-S標準版では、1つのデータストリームを順次暗号化します。Rocca-SX2では、2つのデータストリームを並列に暗号化し、AVX-512の512ビット幅を活用して、2つの256ビットストリームを同時処理します。Rocca-SX4では、4つのデータストリームを並列に暗号化し、複数のAVX-512レジスタを使用します。
並列化により、CPUの演算ユニットを最大限に活用でき、単一ストリームでは利用できなかったスループットを引き出すことができます。特に、ネットワーク機器やストレージシステムなど、複数の独立したデータストリームを同時に処理する環境で効果を発揮します。
ユースケース
高スループットが求められる環境として、データセンター間通信、ストレージ暗号化、VPN集約装置などでの利用が想定されます。
関連リンク
4.2 QUANTUM
プロジェクト概要
量子ネットワーク仕様の策定に向けた準備作業が行われました。
目標
RFCの策定を目指しています。データセンター規模/マルチコンピュータ間接続を初期ターゲットとし、将来的には広域ネットワークも視野に入れ、一連のネットワーク仕様をRFC化することを目標としています。
主な仕様
Quantum Network Architectureとして、全体アーキテクチャの定義、レイヤー構造、プロトコルスタックを策定します。qNodeとして、量子ノードの仕様、インターフェース定義、機能要件を定義します。EPPS（Entangled Photon Pair Source）として、もつれ光子対ソースノードの仕様、量子もつれの生成・配布を規定します。
オープンソースソフトウェア
QuISP（Quantum Internet Simulation Package）は、量子インターネットシミュレーター、ネットワークトポロジーのモデリング、プロトコル検証の機能を提供します。
PnPQ（Plug and Play Quantum）は、テストベッド制御ライブラリとして物理デバイスの制御を行います。
TDC Toolkitは、高精度時間タグ付けと量子状態の測定タイミング制御を提供します。
量子ネットワークの将来
量子ネットワークの実現により、QKD（Quantum Key Distribution）による絶対に安全な通信、量子テレポーテーション、分散量子コンピューティング、そして古典インターネットとの共存が可能になります。
まとめ
IETF 124 Hackathon Part 3では、AI/LLM、DNS/アプリケーション、IoT/インネットワークコンピューティングの最新プロジェクトを紹介しました。
主なトレンド
今回のハッカソンで見られた主なトレンドとして、まずAI/LLMのネットワークへの統合が挙げられます。PacketScopeによるインテリジェントな脅威対応や、AI-networkによるAI/ML向けネットワーク最適化が注目されました。
次に、エッジコンピューティングの進化が顕著でした。5G-I2NSFによる5Gとの統合や、I2ICFによるリアルタイム処理が実証されました。
IoTプロトコルの最適化も重要なトピックでした。DNS over CoAPやSCHCなどの軽量プロトコルと、CORECONFによる動的な管理が実装されました。
さらに、DNSエコシステムの拡張として、DELEG、DNS Transport Signaling、BIND/QUIC統合、PQC DNSSECなど、DNSの将来を見据えた多様なプロジェクトが並行して進められました。
最後に、次世代ネットワークへの準備が進んでいます。IPv6の完全移行支援、量子ネットワークの準備、マルチCDNの最適化などが取り組まれました。
IETF 124 Hackathon 全体の総括
3部作を通じて見えたことをまとめます。
Part 2で取り上げたPQCの実用化が加速しており、相互運用性テストの充実と複数の実装が登場しています。
Part 1とPart 3で見たAI/MLとネットワークの融合も進んでおり、自然言語管理、インテリジェント防御、最適化の自動化が実現されています。
Part 3で紹介したエッジ/5G/IoTの統合も進展しており、低遅延処理、リアルタイム対応、大規模展開が実証されています。
参加者へのメッセージ
IETF Hackathonは、仕様を実装し、相互運用性を検証する絶好のチャンスです。次回のIETF 125（2026年3月14-20日、中国・深圳）でも多くのプロジェクトが継続されることが予想されます！
興味のある方はぜひ参加を検討してください！
参考リンク
シリーズ記事
- Part 1: 概要・ネットワーク管理・ルーティング編
- Part 2: セキュリティ・PQC・暗号技術編
- Part 3: アプリケーション・AI・IoT編（本記事）
最後に、GMOコネクトでは研究開発や国際標準化に関する支援や技術検証をはじめ、幅広い支援を行っておりますので、何かありましたらお気軽にお問合せください。
一緒に働きたい人も気軽にコンタクトを取ってください！