IPの「細いウエスト」を緩める：ネームサービスとWebサービスのためのAddressing Agility

ネットワーク指向やWeb指向のサービスを大規模に展開する上で、IPアドレスの割り当てに伴う問題が革新の妨げになっています。アーキテクチャの変更時、特に新システムの設計開始時には必ず、まず以下で触れる一連の事項について検討しなければなりません。

• IPアドレスのどのブロックを使うか、あるいは使えるか。

• 手持ちのIPv4アドレスで足りるか。足らなければどこで、またどのように入手するか。

• IPv6アドレスをどのように使うか。それによりIPv6の他の用途に影響はあるか。

• 移行に際し、必要になる細かな計画、チェック、時間、人材はどのようなものか。

IPアドレスの懸念の解消には、時間も費用もリソースもかかります。40年以上前に登場したIPの先見性と弾力性を思い返すと、こうした心配をしなければならないことは意外かもしれません。IPアドレスはその設計からして、いかなるネットワークでも気にする必要なく使えるべきものです。ところが、そのIPアドレスこそが、些細で重要に見えない（設計段階では見えない、または見えてこない）のに、規模が大きくなると必ず露見する弱点であったことが、インターネットの発展に伴って明らかになりました。

1つわかっているのは、「アドレスを増やす」ことが答えであってはならないということです。IPv4では、その種の考え方は希少性を高めて市場価格のさらなる上昇につながるだけです。IPv6は間違いなく必要ですが、それは解決策の一部に過ぎません。たとえば、IPv6では割り当ての最小単位（パーソナルな利用のみ）は/56がベストプラクティスです。つまり、2⁷²、約4,722,000,000,000,000,000,000個のアドレスです。この規模の数字を理論的に説明することは、とてもできませんよね。

1つわかっているのは、「アドレスを増やす」ことが答えであってはならないということです。IPv4では、その種の考え方は希少性を高めて市場価格のさらなる上昇につながるだけです。IPv6は間違いなく必要ですが、それは解決策の一部に過ぎません。たとえば、IPv6では割り当ての最小単位（パーソナルな利用のみ）は/56がベストプラクティスです。つまり、2⁷²、約4,722,000,000,000,000,000,000個のアドレスです。この規模の数字を理論的に説明することは、とてもできませんよね。

このブログ記事では、WebサービスにとってIPアドレスの割り当てがなぜ問題なのか、根底にある原因を説明してから、当社でAddressing Agilityと呼んでいる革新的なソリューションとこれまでに学んだ教訓について述べていきます。最も素晴らしいのは、Addressing Agilityでどういう種類の新システムや新アーキテクチャが可能になるかという点かもしれません。詳細は、最近ACM SIGCOMM 2021で報告された文書をお読みください。ここでは、わかったことのいくつかを要約してお伝えします。

確かに、1つのアドレスに含められる名前の数に制限はありません。どんな名前でも新たなクエリのたびに_どこででも_変わり得ますし、アドレスの変更はどんな理由でも可能で、サービスのプロビジョニングであったり、ポリシーやパフォーマンスの評価であったり、未だ直面していないようなその他の理由である可能性もあります。

以下では、上記の教訓がすべて真実である理由とそのことを学んだ経緯、それらが_あらゆる規模の_HTTPサービスやTLSサービスにとって重要である理由を説明します。当社が得た重要な見識で、構築の基礎としているのが、「インターネットプロトコル（IP）の設計は国際郵便制度に似ていて、アドレスに名前を表記する必要は今までなかったし今後も決してないし、必要とすべきでもない」ということ。ただ、アドレスを名前の表記であるかのように扱うことが時々あるというだけなのですが、この文書では、すべての名前がそのアドレスまたはアドレス群のすべて（アドレスが1つの場合も）を共有すべきであることを示しています。

IPアドレスを名前とリソースに人為的に紐づけるのは、数十年前からの慣例です。インターネット運用のためのアーキテクチャとソフトウェアが、1台のコンピュータが1つの名前と（通常は）1つのネットワークインタフェースカードを持つ環境から発展した経緯を考えると、この慣例は理解できます。1つのIPアドレスが名前やソフトウェアプロセスと関連づけられる形でインターネットが発展したことも、必然の流れでしょう。

名前を使う必要がほとんどなくてリスニングプロセスの必要もわずかなエンドクライアントやネットワーク事業者には、こうしたIPのバインディングはほとんど影響しません。しかし、名前とプロセスにまつわるこの慣例は、_すべての_コンテンツホスティング、配信、コンテンツサービスプロバイダー（CSP）にとって大きな制約となります。アドレスはいったん名前、インタフェース、ソケットに割り振られてしまうとほぼ静的なものになり、変更が可能だとしても難しく、計画性と周到さが必要になります。

IPの「細いウエスト」が、インターネットを実現する立役者となったわけですが、ちょうどトランスポートプロトコルに対するTCP、アプリケーションプロトコルに対するHTTPと同じように、IPは革新を妨げる足かせになってしまいました。この閉塞状態を表したものが下図で、本来別個である通信のバインディング（名前との）と接続のバインディング（インターフェースやソケットとの）が、推移的依存関係を作ってしまったことがわかります。

この推移的な「縛り」は、一方を変更すると他方にも影響する可能性があるため断ち切ることは困難です。しかも、サービスプロバイダーは、名前とは別個に存在するポリシーやサービスレベルを表すために、IPアドレスをよく使います。そのため、本来その必要はないにもかかわらず、結局はIPバインディングも考慮しなければならなくなるのです。

別の言い方をすれば、新しい設計やアーキテクチャを考案する際や、リソースの配分改善を考える際に、まず自問すべきことが「どのIPアドレスを使うか」とか「このためのIPアドレスがあるか」であってはならないということです。そうした問いとその答えは、開発や革新を遅らせます。

私たちは、IPバインディングは人為的であるだけでなく、そもそも先見性をもって作られたRFCと基準に照らして考えれば、IPバインディング自体が間違っているということに気が付きました。実際、IPアドレスが到達可能性以外の何かを表記するものだという考え方は、元来の設計に反しています。もともとのRFCと関連草稿で、アーキテクトは「名前、アドレス、経路は区別する。名前は目的物、アドレスは場所、経路は到達方法を示す」と明記しています。上位層プロトコル中のSNIやHTTPのホスト名といった情報とIPを関連づけることは、レイヤリングの原則に明らかに反します。

もちろん、私たちの取り組みは決して独立したものではありません。むしろ、長年進められてきたIPアドレスを従来の使い方から切り離す動きを完結するものであり、その土台には、先人の偉大な功績があります。

過去20年間を振り返ると、アドレス割り当てのアジリティ追求の動きがしばらく前から続いており、Cloudflareがそれに深く関与してきたことがすぐわかります。

数十年続いたIPとネットワークカードインタフェースとの一対一のバインディングが初めて解かれたのは、数年前にGoogleのMaglevが等コストマルチパス（ECMP）とコンシステントハッシュ法を組み合わせてトラフィックを1つの「仮想」IPアドレスから多数のサーバーへ分散した時です。ちなみに、元来のインターネットプロトコルRFCではこうしたIPの使い方は除外されていて、仮想でもありません。

以来、GitHub、Facebookなどで類似のシステムが多数考案されました。CloudflareのUnimogもその1つです。最近ではCloudflareが新たにプログラム可能なソケットアーキテクチャbpf_sk_lookupを設計し、IPアドレスをソケットやプロセスから分離しています。

しかし、名前についてはどうでしょうか。「仮想ホスティング」の価値は、1997年にHTTP 1.1がホストフィールドを必須項目と定義した際に確立されました。複数の名前が単一IPアドレス上に共存できることが正式に認められたのはこれが初めてで、この項目はTLSによってServer Name Indication（SNI：サーバー名表示）フィールドに必ず複製されました。可能な名前の数はIPアドレスの数より多いため、これらの項目の入力は必須です。

将来を考えた時、シェークスピアが投げかけたとの同じ「名前って何？」という疑問が湧いてきます。もしインターネットが話せたならば、こう答えるでしょう。「その名前と別のアドレスを結び付けても、同じように到達できます」。

また、この質問が「アドレスって何？」であったとしても、インターネットは同様に「そのアドレスと別の名前を結び付けても、同じように到達できます」と答えるはずです。

こうした「答え」の背後には、ある言外の意味が存在します。それは、名前とアドレスのマッピングが、any-to-any（多対多）だということです。もし、それが事実であれば、1つの名前から1つのアドレスに到達できる限り、1つの名前に到達するために使うアドレスは、任意でよいということになります。

実際、1995年にDNSベースの負荷分散が導入されて以来、1つの名前に対してあるバージョンの複数アドレスが利用可能になっています。それならば、すべての名前に対してすべてのアドレスを、あるいは、すべての名前に対して、一時的に任意のアドレスを使わないのはなぜでしょうか。さらに言えば、すべての名前に対して単一のアドレスを使うこともできるはずです。これについては以下で取り上げますが、まずはアドレス割り当てのアジリティを実現する方法についてお話しましょう。

アドレス割り当てのアジリティを実現する際に鍵となるのは権威DNSです。レコードや検索テーブルなど何らかの形で格納された静的な「名前-IP」マッピングではありません。クライアントの視点から見れば、そのバインディングは「クエリ時に」のみ現れます。現実的なマッピングの使い道全体を見ても、1つの名前と1つのアドレスを結び付けることが可能だったとして、リクエスト存続時間内で最後の可能な瞬間は、クエリ応答時になります。

だとすれば、名前のマッピングが行われるのは何らかのレコードやゾーンファイル中ではなく、応答が返信される瞬間だということになります。これは微妙ですが重要な違いです。現在のDNSシステムは1つの名前を使ってアドレス群を検索しており、返信する特定アドレスを何らかのポリシーに従って決定する場合が時々あります。この概念を示したのが下図です。クエリが到着すると、その名前に紐づけられたアドレスをルックアップが検索し、そうしたアドレスの1つまたは複数を返してきます。大概はサービスレベルや地理的カバレッジなど追加的なポリシーやロジックでフィルターをかけ、選出されたアドレスをさらに絞っていきます。ここで重要なことは、アドレスはまず名前で識別され、ポリシーはその後で適用されているという点です。

(a) 従来の権威DNS

(b) Addressing Agility

アドレス割り当てのアジリティは、この関係を逆にすることによって成立します。Cloudflareのアーキテクチャは、IPアドレスを名前にあらかじめ割り当てるのではなく、ポリシーありきの設計になっています。そのポリシーが名前を含む場合と、含まない場合があります　　（Cloudflareの場合は含みません）。たとえば、ポリシーを場所やアカウントタイプなどの属性で表現し、名前は無視するという方法です（Cloudflareのデプロイメントではこの手法が採用されています）。それらの属性によって、そのポリシーに関連するアドレスプールが特定されます。プール自体は、そのポリシーだけに該当することもあれば、他のプールやポリシーと共通する要素を持つこともあります。しかも、プールに属すアドレスはすべて同等です。つまり、それらのアドレスはどれでも、DNSクエリ名の検査をすることなく返信可能で、ランダムに選んでも差し支えないということです。

ここで、クエリごとの応答について注目すべき推察が2点ありますので、それらを少し考えてみましょう。

i. IPアドレスは実行時、またはクエリ時に計算と割り当てができ、実際にそのようにされています。

ii. 「IP-名前」マッピングの存続時間は、その後の接続時間とダウンストリームのキャッシュのTTLのうち、どちらか長い方になります。

ここが大事な点で、バインディング自体は本来短時間のもので、それ以前のバインディングやリゾルバー、クライアント、目的にかかわらず変更が可能だということを意味しています。また、規模は問題になりません。エッジでこれをデプロイしたCloudflareの経験から知りえたことです。

当社のデプロイメントについてお話する前に、誰もが認識しているのにあえて見ないようにしていると言わざるを得ない、IPv6の話をしましょう。まず明確にしておきたいのが、この記事中のIPv4の文脈で述べたこと_すべて_がIPv6にも同様に該当するということです。国際郵便制度と同じように、カナダでもカンボジアでもカメルーンでもチリでも中国でも、アドレスはアドレスであって、比較的静的で柔軟性に欠けるという性質も同様です。

確かにこの2つは似た者同士ではあるものの、明らかな疑問は残ります。Addressing Agilityを追求する理由のすべてが、単にIPv6へ移行することで解消できるのか、という疑問です。意外かもしれませんが、答えは絶対に「否」です。IPv6はアドレス枯渇問題の緩和にはなるかもしれません。少なくとも現在生きている人の寿命が尽きるまでくらいなら大丈夫でしょう。しかし、IPv6のプレフィックスやアドレスが豊富にあると、名前とリソースにバインディングする理由の説明が難しくなります。

また、IPv6アドレスが豊富にあると非効率になる恐れもあります。というのは、運用者がビット長やプレフィックスのサイズを活用してIPアドレスに意味を埋め込む可能性があるからです。これはIPv6の強みではありますが、どのようなプレフィックスのアドレスでも多数が使われないままになることを意味しています。

ここで明言しておきますが、Cloudflareはご存知の通りIPv6の熱心な支持者です。アドレスが豊富にあって長持ちすることはもちろん、支持する理由は十分にあります。とはいえ、アドレスを名前とリソースに紐づけるという点ではIPv6も代わり映えしません。アドレスのアジリティこそが、その存続時間中の柔軟性と応答性を保証するのです。

アーキテクチャとその移行可能性について、最後にもう1点付け加えます。Addressing Agilityは、権威DNS上で稼働するいかなるサービスにも使え、むしろ使うのが望ましいものです。もちろん、他のコンテンツ指向サービスプロバイダーも候補ですし、小規模の運用者も然りです。独自の権威サーバーを運用する組織をいくつか挙げると、たとえば大学、企業、政府などがです。運用者が返信されたIPアドレス上で接続を受け入れることができる限り、アドレス割り当てのアジリティの恩恵をすべての者が結果として享受できる可能性があります。

当社は2020年6月からエッジでAddressing Agilityを実践的に運用しています。本番環境のトラフィックは以下の通りです。

• 2000万件以上のホスト名とサービス

• カナダの全データセンター（合理的な範囲の人口と複数のタイムゾーン）

• IPv4が /20（4096アドレス）、IPv6が /44

• 2021年1月から6月までは、IPv4が /24（256アドレス）

• 各クエリに対し、プレフィックスにランダムなホスト部を生成

結局、アジリティの真価が問われるのは、サーバーで受信するクエリそれぞれに対してランダムなアドレスが生成されるという最も厳しい条件下です。そこで、当社はこのアイデアを実際にテストしてみることにしました。2021年6月、モントリオールのデータセンターとそのすぐ後にトロントのデータセンターにおいて、2000万強のゾーンすべてを単一のアドレスにマッピングしました。

1年間で、1つのドメインに対して実行されポリシーでキャプチャされた各クエリが、ランダムに選ばれた1つのアドレス（4096個のアドレス群から256個に絞り、そこから1個を選択）を受信しました。この1つのアドレス（群）を当社内ではAo1と呼びますが、それについては後ほどお話します。

読者の皆さんの中には、次のような疑問を抱えている方がいるかもしれません。

• このテストでインターネット上の何が壊れたか？

• Cloudflareのシステムへの影響は？

• 何が起こっているか見ることが可能ならば、何が見えるか？

これらの質問に端的に答えると、すべて_「何もない」です。しかし、アドレスのランダム化によってインターネットに依存するシステム設計の弱点が露見したことは、重要な点です。この弱点は_いつも、例外なく、設計者が達成できる以上の意味をIPアドレスに持たせようとすることから起こります。（ちなみに、それらの弱点はすべて、単一のアドレス、つまり「Ao1」を使えば回避できるものなのです。）

「何もない」の真の意味をよりよく理解するため、上記の問いに、下から順に回答していきましょう。

何が起こっているか見ることが可能ならば、何が見えるか？

答えを下図の例で示します。当社のデプロイメントの対象外である「その他地域（Rest of World）」のすべてのデータセンターから、1つのゾーンに対する1つのクエリに同じアドレスが返信されています（Cloudflareのグローバルエニキャストシステムとはそういうものです）。一方、デプロイメント対象地域のデータセンターに来た各クエリは、ランダムなアドレスを受信します。このことは、2つのデータセンターへの次のdigコマンドに見てとれます。

後続するリクエストトラフィックはどうなるか知りたい方がいるかもしれません。お察しの通り、この2000万余のドメインの_いずれ_に対しても、接続リクエストをアドレスプール中の_全_アドレスで受け入れるようにサーバーが構成されているということを意味します。

それにしても、Cloudflareを取り巻くシステムには変更が必要だったのではないか？

いいえ。これは、権威DNSのためのデータパイプラインに対するドロップインの透明な変更です。BGP、DDoS、ロードバランサー、分散型キャッシュにおけるルーティングプレフィックスの通知では、変更は一切必要ありませんでした。

ただし、1つ興味深い副次的な作用がありました。IPアドレスのランダム化は、ハッシュテーブルの構成における優れたハッシュ関数と同じように、恣意的なサイズのインプットを一定数のアウトプットに均等にマッピングします。その効果、ランダム化前後のIP 1つあたりの負荷を尺度として測ることができます。下のグラフは、7日間にわたって1か所のデータセンターで受信したリクエストの1％をサンプルとして得たデータです。

Addressing Agility導入前

/20でランダム化

/24でランダム化

ランダム化前は、CloudflareのIPスペースのごく一部について、(a) IPあたりのリクエスト数（左側のy1軸）の最大値と最小値の差は3桁、同様にIPあたりのバイト数（右側のy2軸）ではほぼ6桁です。ランダム化後は、(b) 1回の /20で得られたドメイン（以前は複数 /20）すべてについて、それぞれ2桁と3桁に縮小しています。これをさらに進めて (c) では /24にし、クエリごとに2000万以上のゾーンを256のアドレスにランダム化すると、負荷の差が縮小して小さな定数係数になります。

IPアドレスでリソースをプロビジョニングすることを考えているコンテンツサービスプロバイダーにとっては、これは問題かもしれません。顧客が生成する負荷の事前予測は困難な場合があります。上のグラフは、今後進むべき最善の道は「すべてのアドレスをすべての名前に与えること」だということを証明しています。

では、やはり広義のインターネット上で何かが壊れるのでは？

しかし、ここでも答えは「否」です。正確にいえば、「否、ランダム化で破壊されるものは何もない。・・・ただ、システムやその設計の弱点が露見する可能性がある」ということになるでしょう。

アドレスのランダム化で影響を受ける_可能性のある_システムは、前提として、IPアドレスに到達可能性以外の何らかの意味を持たせようとしているようです。Addressing AgilityはIPアドレスのセマンティクスとコアインターネットアーキテクチャを保持し、復元さえしますが、意味を推測するソフトウェアシステムを破壊してしまいます。

まず、なぜ問題ないのかをいくつかの例で見てみましょう。続いて、弱点を回避するような小さな変更をAddressing Agilityに加えます（単一のIPアドレスを使用）。

• HTTP Connection Coalescingによって、クライアントは既存の接続を再利用して別のオリジンからリソースをリクエストすることができます。Firefoxなど、URIのオーソリティが接続とマッチすれば結合を許可するクライアントには影響はありません。しかし、URIホストがその時々の接続と同じIPアドレスとの解決を要求するクライアントは失敗します。

• TLSベースやHTTPベースでないサービスにも影響が出るかもしれません。その一例がsshで、「ホスト名-IP」のマッピングをknown_hostsで保持しています。この紐づけ自体は理解できるものの、時代遅れですし、複数のIPアドレスを返信するDNSレコードが多々ある現状では既に壊れています。

• SNI非実装でTLS証明書を取得するには、専用のIPアドレスが必要です。SNIを実装しない場合、各アドレスでサポート可能な証明書は1つだけであるため、プロバイダーはプレミアム価格を課さざるを得ません。IPとは別に、より大きな問題はSNI非実装でTLSを使うことです。当社では、できればこの有難くないレガシーを終わらせるべく、SNI非実装を理解するための取り組みを開始しました。

• 宛先IPに依存するDDoS攻撃対策にも、当初は支障が出るかもしれません。当社がお伝えしたいAddressing Agilityのメリットは次の2つ。1つ目は、IPのランダム化によって攻撃の負荷が使用中のアドレスすべてに分散され、事実上、第3層のロードバランサーとして機能することです。2つ目は、IPアドレスを変更することで、DoS攻撃が軽減されることはしばしばありますが、Addressing Agilityはその性質を受け継いでいることです。

当初は2000万以上のゾーンが何万個ものアドレスにバインディングされていましたが、それを/20で4096のアドレス、さらには/24で256のアドレスに減らし、そこからサービスを提供することに成功しました。ただ、次の疑問はやはり出てくるでしょう。

n個のアドレスのランダム化ができるなら、なぜ1つのアドレスでランダム化しないのか？

まさのその通りです。先ほど、IPアドレスのランダム化はハッシュテーブルの構成における優れたハッシュ関数と同じ、と言いました。うまく設計されたハッシュベースの構造は、構造のサイズにかかわらず、たとえサイズが1であっても、その特性を保持するという点がミソです。Addressing Agilityの基礎が真に試されるのは、そうしたサイズの縮小時でしょう。

だとしたら、ということでテストしてみました。/20のアドレス群から /24へ、さらに2021年6月からは /32、そして均等に /128（Ao1）へ。結果は、大丈夫どころか_実に_うまくいっています。ランダム化によって露見するかもしれない懸念事項は、Ao1が解決します。たとえば、非TLSサービスや非HTTPサービスは信頼性の高い（少なくともランダムではなく、名前に関するポリシーの改変がない限り信頼できる）IPアドレスを持っています。また、HTTP接続の結合は簡単に外れ、Ao1が使われる場合はもちろん結合が増えます。

単一のIPv6アドレスへバインディングすることに対する反論の1つは、アドレスが枯渇する心配がまずないのに不要ではないか、というものです。これはCIDRが登場する以前の立場で、毒にはならないものの無責任だと考えます。上述した通り、IPv6アドレスの数が多いだけに理由の説明は容易ではありません。自問すべきは、なぜ単一のIPv6アドレスを使うのかではなく、「なぜ使わないのか」なのです。

Ao1によって、IPランダム化のまったく別の意味合いも明らかになりました。一見些細な行動の効果を増幅することで、インターネットのルーティングと到達可能性が将来どうなるのかを垣間見れたといえるでしょう。

その理由は？宇宙にあり得る可変長の名前の数は、固定長のアドレスの数を常に上回ります。つまり、鳩の巣原理によって、単一のIPアドレスを複数の名前、無関係の当事者が提供する異なるコンテンツの間で共用しなければならないということです。

Ao1によって増幅されたアップストリームで起こり得る効果は、触れておくべきでしょうから以下で説明します。ただ、これまでのところ、それらの効果はいずれも当社の評価では発現していませんし、アップストリームネットワークとの対話でも話題に上ったことはありません。

• **アップストリームのルーティングエラーは直接かつ全面的です。**すべてのトラフィックが単一のアドレス（またはプレフィックス）に到着するとなると、アップストリームのルーティングエラーはすべてのコンテンツに等しく影響します。（これが、Cloudflareが不連続のアドレス範囲の2つのアドレスを返信する理由です。）しかし、同じことが脅威のブロックにも該当することに注意してください。

• **アップストリームでのDoS攻撃対策がトリガーされる可能性があります。**単一アドレスにリクエストやトラフィックが集中することが、アップストリームでDoS攻撃と認識されて、設定してあるアップストリームの保護対策をトリガーするかもしれないのです。

どちらのケースも、Addressing Agilityには大量のアドレスをすばやく変更する機能があるため、行動の効果は緩和されます。予防も可能ですが、オープンなコミュニケーションと対話が必要です。

最後に、アップストリームへの影響がもう1つあります。

• **IPv4 NATのポート枯渇が加速するかもしれませんが、IPv6が解決します。**クライアント側から見れば、1つのアドレスに対して許可できる同時接続数の上限は、トランスポートプロトコルのポートフィールドのサイズ（例：TCPでは約65000）によって決まります。

たとえば、Linux上のTCPでは、これは最近まで問題がありました（このコミットとマニュアルページip(7)のSO_BIND_ADDRESS_NO_PORTを参照）。UDPには依然この問題があります。一方、QUICでは接続識別子がポート枯渇を防止できますが、まず識別子を使っていなければなりません。ただ、それが問題だという証拠は今のところありません。

とはいえ、当社で知る限り_単一アドレスを使用するリスクはこれだけであり、それもIPv6への移行によって即解決できる_という点が嬉しいですね。（ですから、ISPやネットワーク管理者はどうぞIPv6の実装を進めてください！）

最後に、冒頭に述べたことを振り返ってみます。どのIPアドレス1つをとっても名前の数が無限で、理由を問わずクエリごとにアドレスを変えることができるなら、_あなた_は何を構築できるでしょうか？

私たちの取り組みはまさしく今始まったばかりです。Addressing Agilityで実現する柔軟性と将来性があれば、新たなシステムやアーキテクチャを構想し、設計し、構築することができます。当社では今後、エニキャストシステムでのBGPルートリークの検出・軽減、評価プラットフォームなどに取り組んでいく計画です。

上で述べたことの技術的な詳細と、この記事の執筆に助力くださった方々への謝辞は、本論文およびショートトーク中にあります。今回触れた新たな可能性がある一方、課題も残っています。以下をはじめ、答えがまだない疑問もたくさんあるでしょう（あくまで例示であり、網羅してはいません）。

• どのようなポリシーを合理的に表現し、また実装できるか？

• 表現する際に使う抽象構文や文法はあるか？

• ポリシーの誤りや矛盾を防ぐために、形式手法・検証は使えるか？

Addressing Agilityは万人向けで、これらのアイデアを広く普及させるためにも必要です。インプットやアイデアをask-research@cloudflare.comまでお寄せください。お待ちしています。

博士号過程または同等のリサーチプログラムに在籍する方で、米国またはカナダ、EUまたは英国で2022年のインターンシップをお探しの方、このようなプロジェクトへの貢献や、Cloudflareのトラフィック・アドレス管理システム開発への協力に関心がある方を、当社Addressing Engineeringチームで募集しています。ご応募ください！