IETF118 参加報告〜Hackathon での成果と WG session 紹介〜

イノベーションセンターの三島と深川です。普段の業務では、Segment Routing を始めとする経路制御技術や、IPFIX や Streaming Telemetry などの監視技術の検証・運用、高速ソフトウェアルーター「Kamuee」の開発をしています。

我々は 2023/11/04-10 に行われた IETF 118 Prague へ参加しました。この記事では、IETF 118 の参加報告として、主に Hackathon での成果と各 WG の動向などをご紹介します。

(出典: https://www.ietf.org/)

IETF の概要や IETF 117 についてはIETF117 参加報告とおもしろワーキンググループ紹介をご覧ください。

IETF 118 参加報告

以下では、我々が現地で参加した IETF meeting の内容をご紹介します。

IETF 118 の全スケジュールは IETF 118 Meeting Agenda を参照ください。また、IETF の onsite meeting ならではの用語は Guide to IETF Meetings で紹介されています。

Day1-2: Hackathon

IETF meeting では、本会議である Meeting Week に先んじて2日間の Hackathon が開催されます。

IETF Hackathon は、集まった多くの開発者や専門家が、アイデアや便利なツール、標準化にあたっての running code 開発、相互接続性を検証するための場です。

IETF Hackathon では、各自が自由なテーマを設定し、開発に取り組むことができます。テーマは事前に Hackathon Wiki で募集することもできますし、現地で新たにテーマを定めて開発することもできます。

我々は IETF 116 Hackathon 以降、SRv6 ネットワークにおける情報取得や高度な Traffic Engineering (TE) を目的とし、IPFIX exporter を開発しています。それぞれの技術は、Operations and Management Area Working Group (opsawg) にて標準化が行われているため、Hackathon では、opsawg の I-D 著者の方々と連携しながら、パラメータの調整や相互接続試験を実施しています。

我々は IETF 116 Hackathon において、汎用の Linux ルーター上でのアイデアの迅速な実装を目的とし、eBPF/XDP ベースの IPFIX exporter として「Fluvia Exporter」を開発しました。 Fluvia Exporter は NTT Com より OSS として公開しています（リポジトリ）。より詳しい開発背景や設計・実装手法については、ENOG79 SRv6 対応の IPFIX exporter を開発した話をご覧ください。

IETF 117 Hackathon では、IPFIX を用いた SRv6 フローの情報取得を目的とし、Export of Segment Routing over IPv6 Information in IP Flow Information Export (IPFIX) の実装と nfacctd・WireShark との相互接続を実現しました。この実装により、Segment List や Segment Left などによる SRv6 フローの識別や追跡が可能となりました。

IETF 118 では、「IPFIX On-Path Telemetry with SRv6」というテーマを主催しました。このテーマでは、SRv6 フローの hop-by-hop な遅延メトリックの取得を目的とし、Export of On-Path Delay in IPFIX の各機能を開発します。

Hackathon 開始時点では、2 つの exporter（FD.io VPP・Huawei VRP）と、collector（nmacctd）の実装が存在していました。今回我々は、以下の2つのモチベーションで Hackathon に取り組みました。

1つめは、Fluvia Exporter への on-path delay の Information Element (IE) の実装、2つめは、WireShark dissector の実装です。この2つの実施により、SRv6 ネットワークにおける on-path delay の取得と、取得したパケットのプロトコル解析が可能になります。

Fluvia Exporter への IE 実装

Fluvia Exporter に対し、今回対象となる IE を実装します。実装したコードはこちらです。

実装対象である IE の Element ID は、IANA での割り当て待ち（TBD）となっているため、今回は相互接続用に仮に定めた番号を用いて実装し、OSS の IPFIX collector である nfacct の既存実装との相互接続を目指します。

今回実装する on-path delay 取得の仕組みを図に示します。

on-path delay では、遅延の取得のため、IPv6 の拡張ヘッダである hop-by-hop options header で Encapsulation された In-situ OAM (IOAM) と呼ばれるプロトコルを利用し、パケットに送出時のタイムスタンプを埋め込みます。そのタイムスタンプと、各ルーターでのパケット受信時のタイムスタンプの差を取得することで、図の D1/D2/D3 のような送信遅延を取得できます。（ごく短いタイムスタンプの差を取る関係上、機器間で PTP 等での高精度な時刻同期が行われていることが前提となります。）

on-path delay を取得するための IPFIX exporter のパイプラインを上図に示しました。パイプラインは、capturer・meter・exporter の3つのコンポーネントから構成されます。

capturer: パケットを取得するコンポーネント。IOAM timestamp を取得し、受信時のタイムスタンプと共に meter に送信する
meter: パケットを処理し、IPFIX data を生成するコンポーネント。IOAM で付与されたタイムスタンプと機器のシステムクロックのタイムスタンプの差から送信時の遅延を算出し、SRv6 SRH の情報と共に IPFIX data を生成する。
exporter: IPFIX packet を生成し、collector に送信するコンポーネント。

Fluvia Exporter のアーキテクチャを上図に示しました。 Fluvia Exporter は eBPF/XDP ベースに実装されており、eBPF プログラムとして動作する capturer によりパケットを取得し、User land の meter/exporter で IPFIX パケットを生成します。IPFIX のパケットフォーマットは Go のライブラリとして実装しています。

今回は、capturer への IOAM パケットの取得機構の実装・meter へのタイムスタンプ計算処理の実装・IPFIX ライブラリへの IE の実装を行いました。

上図に、実装した IPFIX ライブラリの例を示しています。

相互接続用の仮の Element ID として、521・523・525・527 の4種を実装しています。（注: 522・524・526・528 として実施済みの nanoseconds は draft-ietf-opsawg-ipfix-on-path-telemetry-01 にて廃止されたため、Fluvia Exporter からも今後削除予定です。）

それぞれの IE のデータ構造と処理を IPFIX ライブラリに定義します。

その他、今回の PR には eBPF によるパケットの取得や、タイムスタンプの計算処理なども含まれているので、もし興味があれば是非読んでみてください。

上図の通り、nfacctd との相互接続を確認しました。ログから、すでに実装されていた SRv6 SRH の Element ID (495・498・492・493・496) と、今回実装した Element ID (521・523・525・527) がそれぞれ確認できます。

これにより、Fluvia Exporter に on-path delay の IE が正しく実装できたことが確かめられました。

WireShark dissector の実装

WireShark は、GUI のネットワークプロトコル解析ツール（network protocol analyzer）です。リアルタイムに取得したパケットや pcap ファイルに記録したパケットの解析ができます。

WireShark は多くのネットワークプロトコルに対応していますが、今回対象とする I-D のように、標準化中などの最新プロトコルには未実装なものも存在します。そのような場合は、dissector と呼ばれるパケットの解析プラグイン追加することで、新たなプロトコルを扱えるようになります。

Hackathon にて実装したコードはこちらです。 IPFIX 自体の dissector はすでに存在しているため、今回必要となる IE に関するコードのみを、I-D で定義されたデータ型を参考に実装しています。

dissector を追記実装した後、WireShark をビルドし実行しました。図の通り、今回実装した on-path delay に関する IE が表示されています。

これにより、Fluvia Exporter への IE 実装と、WireShark dissector 実装をそれぞれ完了し、動作確認を実施できました。

最終発表

IETF Hackathon 2日目の後半2時間（14:00-16:00）には、それぞれのチームによる最終発表が行われます。発表の希望者は、IETF Hackathon の GitHub organization に参加し、締め切りまでにIETF Hackathon 118 のリポジトリに資料を投稿することで最終発表にエントリーできます。

最終発表では、Hackathon で達成した内容や成果を共有できました。資料はこちらです。

発表は開発時間が終わった直後に始まるため、開発と並行して資料を用意する必要があり少し大変でしたが、とても良い経験となりました！

Hackathon を通じて得られたことと今後について

Fluvia Exporter の実装を I-D の Implementation 例として追記していただきました！今後は IANA による Element ID の払出し後に Fluvia Exporter の実装を修正するとともに WireShark の実装も修正し PR を提出しようと思います。

Hackathon を通じて得られた経験としては、前回に引き続き、I-D 著者の方々と事前のメールや現地会場での交流ができました。その中で、I-D に関連する取り組みを教えていただけたと共に、I-D に関する勘違いを指摘して頂き、実装をより良いものに修正できました。

また、Hackathon Wiki にて募集をかけたことで、他の参加者から取り組みについてメールで質問をいただき、現地にて交流できました。

この開発により、当初目標としていた、SRv6 網の IPFIX による解析と、hop-by-hop の遅延を得ることがそれぞれ達成できました。

次回以降の Hackathon では、現在執筆中の SRv6 SFC の I-D に関する実装や、IPv6 に関する別の I-D の実装などを検討しています。

IETF Hackathon は、I-D の著者や機器の開発者など、最先端のスキルを持つエンジニアと交流し、議論ができる貴重な機会です。今後も是非活動を続けていければと考えています。

Day3-7: WG session

Day3 以降の Meeting Week では、それぞれの WG session が開催されます。他の WG session を含め、全てのスライドや I-D などの資料は IETF 118 の Agenda ページから確認できます。

以降では、我々が参加した WG session のうち、SR に関連して特に面白かったテーマをいくつかご紹介します。

Source Packet Routing in Networking (spring)

spring WG は、セグメントルーティング (Segment Routing: SR) と呼ばれる TE 技術の標準化と拡張を目的とする WG です。

SRv6 compression・ICMP による SRH 情報の報告・SRv6 MUP・SR Policy Candidate Path の検証などのトピックが扱われていました。

その中でも、ICMP の SR Policy 拡張は、SR 網のトレーサビリティを高め、トラブルシューティングに役立てることのできる面白いトピックです。提案では、SID の Endpoint behavior や VPN prefix、Flex-Algorithm なども解析できるような提案がされていました。 ICMP は任意の宛先に対してアクティブな検証ができますが、同じくアクティブに検証する TWAMP や、実トラフィックを用いてパッシブに解析する IPFIX との機能の差なども含め、利点を考慮すべきテーマだと考えています。

Internet Area Working Group (intarea)

intarea WG は、インターネット全体に影響するトピックを議論するための WG です。アドレス空間・IP レイヤーの機能などのテーマが扱わます。

この枠では、Trusted Domain SRv6 (draft-raviolli-intarea-trusted-domain-srv6-02) についての発表が行われていました。

この I-D は、外部からの不正な SRv6 パケットによる攻撃（DoS の送信元詐称や悪意のあるループ等）を防止するため、 trusted domain という概念を導入しています。 trusted domain では、現行の MPLS のように、あるプロトコルはデフォルトでは drop され、明示的に有効化されたインターフェースでのみ転送が行われます。

trusted domain の実装として、本 I-D では SRv6 専用の ether type を割り当てることで、一般の IPv6 パケットと識別可能にすることを提案しています。一方、ether type によるアプローチは SRv6 が持つ IPv6 ネットワーク上に部分的に組み込むことができる利点を妨げるものであり、SRv6 の自由度を下げることが懸念されます。

ether type によるアプローチでは、SR-MPLS 同様に、明示的に有効化するよう設定されたネットワークでしか SRv6 を活用できなくなります。 SR-MPLS と比べた利点として、SID が持つ Function/Argument 領域や Prefix Aggregation、Path Tracing などは残りますが、SRv6 が持つ IPv6 ネットワーク上に部分的に組み込むことができる利点を妨げるものであり、SRv6 の自由度を下げることが懸念されます。

SRv6 の routing security は、今後 SRv6 が広く用いられる技術となる際に重要となる観点です。一方、security のトレードオフとして技術の持つ利点が大きく損なわれることは望ましくないため、より良いアプローチや SRv6 に求める利点について、我々も引き続き注目し検討していきたいと考えています。