IETF117 参加報告とおもしろワーキンググループ紹介

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

今回、我々は 2023/07/22-28 に行われた、IETF 117 に参加しました。この記事では、IETF 117 の参加を通じて得た経験や現地の様子、各 WG の動向などをご紹介します。

IETF (Internet Engineering Task Force) とは

IETF は、インターネット技術の標準化を推進する団体です。標準化の議論は Working Group (WG) 単位で推進され、主にメーリングリストを通じて議論が行われます。メーリングリストは誰でも閲覧・参加が可能です。また、標準化された技術は Internet-Draft (I-D) や Request for Comments (RFC) などとして広く公開されます。

IETF では、年に3回のオンサイトでの会議があり、直近では以下のような日程・開催地となっていました。 (基本的に、アジア/オセアニア・北米・ヨーロッパで、それぞれ1回ずつ開催されます。) オンサイトのミーティングも参加条件はなく、誰でも参加できます。(有料)

IETF 116 が2015年7月以来の7年半振りに日本(横浜)で開催されたこともあり、我々2名は IETF 116 にて初めてオフラインでの参加をしました。

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

IETF 117 (San Francisco) は、サンフランシスコの中心地にある Hilton San Francisco Union Square で開催されました。

IETF 117での参加セッション

以下では、我々が現地で参加したセッションをいくつかご紹介します。 IETF 117 の全スケジュールはこちら： IETF 117 Meeting Agenda

IETF のオンサイトミーティングならではの用語はこちらのページで紹介されています。

Day1-2: Hackathon

IETF のオンサイトでの会議では、本会議である Meeting Week に先んじて2日間の Hackathon が開催されます。（Pre-Meeting Weekend Session） Hackathon では、集まった多くの開発者や専門家が、アイデアや便利なツール、標準化にあたっての running code 開発、相互接続性を検証するための場です。

今回我々は、「IPFIX Exporter w/eBPF」というテーマで、OSS の IPFIX exporter である「Fluvia Exporter」を用いた Hackathon を行いました。

Fluvia Exporter は、IETF 116 Hackathon にて開発を開始した、OSS の IPFIX exporter です。 IETF 116、117 での開発を通じ、opsawg の 2つの I-D (Export of Segment Routing over IPv6 Information in IP Flow Information Export (IPFIX) / Export of On-Path Delay in IPFIX) に準拠しています。

IETF 117 では　opsawg の方々と協力して相互接続検証を行い、無事に動作させることができました。draft-ietf-opsawg-ipfix-srv6-srh-14

Hackathon 期間中以外でも継続的に opsawg の方々とコンタクトをとりながら実装を進めていました。今回の Hackathon では、I-D にはまだ記載されていなかったパラメータなどもその場で議論しながら値を決めるなど、現地で参加したからこそできたことが多くありました。

図は、我々が作成した Hackathon での最終報告資料です。

今回の Hackathon では、SRv6 機能の開発や他の実装 (pmacct・Wireshark) との相互接続を完遂できました。また、フロー毎の hop-by-hop な遅延 (On-Path Delay) の取得機能についても開発を開始しました。こちらは Hakacthon 中には完了できませんでしたが、その後も相互接続を目指し実装を進めております。

対応したそれぞれの I-D の詳細については、"Day3-7: WG session" の章でご紹介します。

また、Fluvia Exporter のより詳しい開発背景や設計・実装手法については、ENOG79 SRv6 対応の IPFIX exporter を開発した話をご覧ください。

Day3-7: WG session

Day3 以降に行われた Meeting Week において、我々が参加した WG session の中から特に面白かったものを抜粋してご紹介します。他の WG session を含め、全てのスライドや I-D などの資料は IETF 117 の Agenda ページから確認できます。

Operations and Management Area Working Group (opsawg)

opsawg は運用や管理に関する技術を扱う WG です。特に、既存の WG の範囲外、もしくは新しい WG を作るほどではない「運用と管理」に関するトピックについて議論し、RFC としてまとめることを目的としています。

この opsawg WG の中で特に我々が注目している技術は、YANG・Telemetry・xFlow などの運用監視に使われるプロトコル群です。ここでは、Hackathon の項目でも触れた2つの I-D の内容を紹介します。

1つめは Export of Segment Routing over IPv6 Information in IP Flow Information Export (IPFIX) です。この I-D は IPFIX で SRv6 の SRH を扱うための新たな Information Element (IE) を提案しており、SRv6 SRH に含まれる Segment List や Segment Left、また Active Segment の情報などさまざまな値を表現可能にしています。

2つめは Export of On-Path Delay in IPFIX です。この I-D は、On-Path Delay を取得するための手法を提案しています。遅延の取得は、機器の持つ Timestamp と、In-situ OAM (IOAM) で得られるパケット送出時の Timestamp の差を取ることで実現されます。計測した Timestamp は、フロー毎に IPFIX の IE に格納し送出されます。このように、ネットワークの中間ノードから情報を取得することを、On-Path Telemetry と呼びます。

上図に、2つの I-D の技術を用いた、SRv6 網における遅延取得手法を示しました。計測対象となるパケットには、SRv6 の Headend ノードにて Direct EXport (DEX) の option Type で Timestamp が有効になった IOAM ヘッダが付与され、送出時の Timestamp が格納されます。 IOAM ヘッダの付与手法は複数提案されていますが、Timestamp を付与する場合、2023/10 時点では IPv6 の拡張ヘッダに付与する実装のみ存在します。

IOAM ヘッダのついたパケットを受け取ったノードは、受信時の Timestamp との差 (D1-D3) を取得した後、フロー毎に統計処理し、IPFIX によりエクスポートします。これにより、フロー毎に hop-by-hop な遅延を取得できます。

似た技術として SRv6 を用いて hop-by-hop の遅延情報も取得可能な SRv6 Path Tracing がありますが、 On-Path Delay は、IOAM が提案しているIPv6/MPLS/Geneve/VXLAN-GRE など、さまざまなプロトコルに適用できる利点があります。

我々は multi-AS SR 網で SRv6/SR-MPLS の双方を運用しているため、幅広いプロトコルに適用できる可能性を持つ On-Path Delay に期待しています。

これらの IPFIX 拡張の活用例の1つとして、opsawg のメンバーにより、Applied Networking Research Workshop 2023 (ANRW '23) にて SRv6 ネットワークのアノマリ検知の成果が発表されていたので、次の章でご紹介します。

Applied Networking Research Workshop 2023 (ANRW '23)

ANRW は ACM/IRTF によるワークショップであり、IETF で議論されたトピックや課題に関連する研究成果を発表するための場です。年1回、7月の IETF と併催されており、ANRW '23 は IETF 117 の Day3 に開催されました。

我々は、共に Hackathon を行った opsawg の方から、「Daisy: Practical Anomaly Detection in large BGP/MPLS and BGP/SRv6 VPN Networks」¹を紹介され、興味を持ったため参加しました。

Daisy では、SRv6 ネットワークを Data-plane・Control-plane・Management-plane の3面で扱い、それぞれの metric を取得します。

各面の metric 取得手法として、Data-plane は Hackathon の項目でも紹介した IPFIXを、Control-plane は BGP Monitoring Protocol (BMP)を、Management-plane は YANG Push (RFC8639、RFC8641) をそれぞれ用います。

最終的にはそれぞれの面で集めたメトリックを用いアノマリ検知を目指しており、そのために不足するプロトコルの標準化を行なっています。

Daisy は、SRv6 で metric を取得する手法をプレーン毎に整理し、それぞれで不足する項目を明らかにして標準化に繋げている点が IETF らしい面白い取り組みであると感じています。

我々の SRv6 ネットワークにおける活用も視野に、今後も注目していきたいと思います。

IPv6 Operations (v6ops)

v6ops WG は IPv6の運用上の課題を解決することを目的とした WG です。この WG では、主な目標として以下を掲げています。

IPv6 の運用上の問題を特定し、解決策や回避策を議論する
IPv4 とのデュアルスタック環境における問題を特定し、解決策・回避策を議論する
IPv6 シングルスタック環境における問題や、IPv6 によるイノベーションについて議論する
運用上の解決策を生み出し、BCP(Best Current Practice)の形で文書化する
IPv6 の運用要件を文書化する

v6ops WG では、ルーティングプロトコルやDNSの運用などのIPv6の運用と展開に関連する議論も扱うこととなっています。

IETF118 において発表が行われた中から、我々が注目している I-D を2つ紹介します。

1つめは Using DHCP-PD to Allocate Unique IPv6 Prefix per Device in Broadcast Networks です。

この I-D では、1つのノードが内部的に複数の IPv6 アドレスを用いる際、DHCPv6-PD を利用し、そのノードにユニークな IPv6 プレフィックスを割り当てるアプローチを提案しています。

通常、特定のセグメントに接続されたデバイスは、同一のプレフィックスから IPv6 アドレスを生成しますが、本提案ではデバイスは DHCP-PD クライアントとして動作し、DHCPv6-PD を介してプレフィックスを要求します。クライアントに割り当てられたプレフィックスは、クライアントのリンクローカルアドレスを指すルートとしてファーストホップルータの経路表にインストールされます。このアプローチにより、あるインターフェースに対する複数アドレスの付与、仮想環境のホスティング、テザリングでのネットワーク提供など、さまざまなユースケースにおける複数の IPv6 アドレスの管理を効率的に実現できます。

2つめは、IPv6 only iterative resolver utilising NAT64です。

この I-D は、NAT64 を活用した IPv6 シングルスタック環境において DNS リゾルバーを構成する際の注意点や、修正すべき項目について提案しています。現在の RFC3901(BCP91) では、リゾルバーは IPv4-only もしくは dual stack であるべき(SHOULD)としていて、IPv6シングルスタック環境ではこの SHOULD の要件を満たすことができません。また、名前解決の問い合わせ先となる権威サーバも、IPv6で到達できなかったり、A レコードしか登録されていないことが多々あります。

このドラフトでは特に、上記のような前提では IPv6 シングルスタックの環境下で自前のリゾルバーを運用できないという問題に着目し、NAT64 を用いて解決するためのアプローチについて提案しています。

Source Packet Routing In NetworkinG (spring)

spring WG は、セグメントルーティング (Segment Routing: SR) と呼ばれる Traffic Engineering (TE) 技術の標準化と拡張を目的とする WG です。 Segment Routing を実現するデータプレーン技術として、MPLS(SR-MPLS)、IPv6(SRv6) の両者について議論が行われています。この WG では、SR の運用・管理・TE について扱うだけでなく、他のプロトコルとの相互運用についても議論が行われています。

その中で、特に面白かったものとしては、Problem statement for Inter-domain Intent-aware Routing using Color があります。

この I-D では、複数の AS 同士の SR 網を相互接続することを目的とし、AS を超えて VPN を構成するための Inter-AS option の選び方や、各 AS の Intent を伝えるために考慮すべき点をまとめています。特に AS 超えた Intent の適用については、我々の multi-AS SR でも行っているような BGP Extended Communicty Color を用いる方法についてもまとめられており、Inter-AS についてリファレンスするための良い I-D になっています。

また、もう1つのトピックとしては Service Function Chaining (SFC) に関連した I-D が2つ扱われていました。

1つめは SRv6 Context Indicator SIDs for SR-Aware Services で、SRv6-aware な Network Function に対し、処理のコンテキストを新たな Endpoint behavior を用いて伝える手法を提案しています。

2つめは A Framework for Constructing Service Function Chaining Systems Based on Segment Routingで、Service Function Chaining Architecture (RFC7665) に沿う形で、SR を用いた SFC のアーキテクチャを整理しています。

SFCについては、我々のチームでも神奈川工科大学・ミハル通信株式会社との共同研究において SRv6 を用いた SFC を活用しているため、今後も注目していきたいと思います。

BGP Enabled ServiceS (bess)

bess WG は MP-BGP を用いたサービスについての標準化を行なっている WG です。主要なターゲットは、L3VPN・L2VPN などの VPN 技術であり、データセンターネットワークにおける BGP を用いた VPN のスケーラビリティや DC 環境特有のメカニズム、VPN 技術を用いた SFC (Service Function Chaining) 等のサービスをサポートするオーバーレイのトポロジの構築なども対象としています。また、bess WG では、データプレーンでのカプセル化については直接扱わないことになっています。

面白かった内容としては、VPN の Inter-AS option BC を標準化するための I-D (VPN Inter-AS option BC) が提案されていました。

VPN Inter-AS option は、異なる AS 間で VPN を相互に接続するための技術であり、RFC 4364 で標準化されています。この RFC の Section 10. では、接続手法を a)-c) の3種に分類しています。

a) AS 間で VRF 同士を接続することで、VPN を接続する手法
b) eBGP で VPN 経路を広告することで、隣接する AS との間でも VPN を構成し、E2E な VPN を疎結合に接続する手法
c) 各 AS の RR 間で、multi-hop eBGP により VPN 経路情報を交換することで、AS を超えた E2E の VPN を構成する手法

上記の RFC から、一般にそれぞれの方法を Inter-AS option A、option B、option C と呼称します。図解を添えた各 option の詳しい解説は [Multi-AS Segment Routing 検証連載 #2] SR-MPLS L3VPN in Multi-AS でも解説しています。

一方、今回提案された option BC では、option B のように ASBR 間で VPN を接続しつつ、option C のように E2E な VPN を構築します。

option BC は、option B のように AS 毎に SID の名前空間を分離した NW の作成が実現できます。ただし option BC では、option C のように E2E で SR Policy を作るというようなことはできないため、あくまで疎結合な Inter-AS のユースケースにのみ適していると感じています。

Post-Quantum Use In Protocols (pquip)

pquip WG は量子コンピュータに耐性を持つ暗号 (PQC: Post Quantum Cryptography) の適用に関する支援を目的としたワーキンググループです。従来の暗号が量子コンピュータによって破られる可能性が高いため、PQC の導入とその運用ガイダンスを作るのが主な目的です。

具体的には、Post-Quantum Cryptography for Engineers などの I-D が出されており、PQCの運用や導入のベストプラクティスを文書としてまとめています。

他の WG とは異なり、既存のプロトコルを更新したり、暗号メカニズムを定義・評価するワーキンググループではないというのが特徴です。

Side Meetings and Private Meetings

Side Meeting とは、WG session とは別に開催される有志によるミーティングです。 IETF 公式が用意した Wiki にて募集する Public Side Meeting と、随時開催する Private Side Meeting の2種が存在します。

今回我々は、Hackathon の場で取り組みに興味を持って頂いたエンジニアや、NTT Com の業務に関連する US のエンジニアとの間でセッション外での Side Meeting やランチセッションを複数行いました。業務内容に関わるものもあるため内容は割愛しますが、今後に繋がる話も生まれたため、現地に参加するメリットの1つであったと感じています。

IETF Social は、IETF の参加者に向け、主催者から有料で提供される懇親の場です。 IETF 117 Social は Nokia 主催で、サンフランシスコ近代美術館 (San Francisco Museum of Modern Art、SFMoMA) で行われました。

会場では飲食物も提供され、他のエンジニアと自由に交流できます。また近代美術館での開催ということで、2F に展示された一部の作品を自由に見ることができました。

Social の場でも I-D に関する今後の実装や共同研究等について他のエンジニアと議論でき、とても有意義な会になりました。

Day7: IETF終了後 - (NTT Research, Inc.)訪問

今回会場となった San Francisco 市内から車で南に 30分〜1時間程進むと、シリコンバレーがあります。

我々は、IETF 117 終了後にシリコンバレーの SunnyVale にある (NTT Research, Inc.) を訪問しました。 NTT Reaserch は、シリコンバレーに拠点を持つ企業で、暗号学・物理学・医療情報学などさまざまな分野の基礎研究を目的とする組織です。オフィスでは現地での取り組みや研究内容についてご説明いただきました。

また、すぐ近くには Apple をはじめとするビッグテックのオフィスが多数あるので、帰国前に立ち寄ることができました。

参加してみての感想と今後について

今回、IETF 117 に参加してみての感想として2つのことを感じています。

1つめは現地でのコミュニケーションの重要性についてです。今回の IETF では、Hackathon や Private Side Meeting を通じて、現地のエンジニアと議論ができました。どちらの取り組みでも今後の標準化や PoC の実施などにつながる話を得ることができ、リモートからの参加ではなし得ない成果を上げることができました。

2つめは Hackathon の成果です。 IETF 117 Hackathon では、SRv6 IE の実装を実施し、無事に相互接続まで達成できました。計測したデータの具体的な活用手法や我々の活用案など、今後に繋がる話ができたのも良い点であったと感じています。

IETF Hackathon は 1日を通じ濃密なコミュニケーションをとることのできるいい機会であるため、ご興味のある方は是非参加をお勧めします！

次回 IETF118 Prague の参加登録は 8/14 より開始済みです：IETF118 Register Early Birds の締切は 10/23 23:59 (UTC) なので、参加される方は忘れずにご登録ください。