BGPフルビューで無料のIPv4を探しています

私たちは皆、IPv4アドレスがすでに 一度以上 終わったことを知っています。 最近では、 Habrahabrを含め、議論に非常に人気のあるトピックでした 。彼らは計画と予測を行い 、 損失を計算しました 。 2016年ですが、IPv4はまだ運用中です。

4月21日、RIPE NCCはIPv4アドレスの枯渇に関する短い技術ニュースを公開しました。 実際、ニュースの意味は、 スケジュールが更新され、現在の位置が表示され、RIPEが自由なアドレスを使用して現在の位置を示しているため、RIPEは/ 8のほぼ完全なブロックに対応しています。 APNICには半分/ 8しかありません。 おそらく、厳しいアドレス割り当てポリシーがその役割を果たし、この非常に最後の/ 8 RIRは非常に長く続きます。

しかし、これはすべて「紙」アドレスに関連しています。 また、インターネットへのルーティングに使用できる実際のアドレスの数は？ より正確には、インターネットへのルーティングに使用可能なアドレスの数は使用されません。 これを計算するために、一意の生きている証人-BGPルーティングテーブルを使用します。

さらに、この計算の結果を計算する方法に関するいくつかの技術的な詳細。

BGPフルビューには、ルーティングに使用可能なすべてのアドレスが含まれており、現在約600,000のプレフィックスがあります。 アドレステーブルは次のようになります。

 * 1.1.8.0/24 216.221.157.162 0 0 0 40191 3257 4134 i
 * 1.1.8.0/24 147.28.7.2 0 0 0 3130 1239 4134 i
 * 1.1.8.0/24 185.44.116.1 0 0 0 47872 3356 4134 i
 * 1.1.8.0/24 80.91.255.137 0 0 0 1299 4134 i
 * 1.1.16.0/20 80.241.176.31 0 0 0 20771 47872 286 49597 i
 * 1.1.16.0/20 185.44.116.1 0 0 0 47872 286 49597 i
 * 1.1.16.0/20 134.222.87.1 750 0 0 286 49597 i
 * 1.1.20.0/24 85.114.0.217 0 0 0 8492 9304 18046 133948 e
 * 1.1.20.0/24 185.44.116.1 0 0 0 47872 9304 18046 133948 i

計算には、プレフィックス自体（最初の列）のみが必要です。

プレフィックスは昇順でソートされ、同じネットワークの短いプレフィックスは常に長いプレフィックスよりも先になります。 これにより、テーブル内のスペースの検索が大幅に簡素化されます。これは、次の3つの状況のみが可能なためです。

1. 1つのプレフィックスに別のプレフィックスが含まれる（最初のプレフィックスに2番目のプレフィックスが含まれるが、その逆は含まれない）、またはそれらが等しい。
2. プレフィックスは、短いマスクで1つにまとめられます。
3. プレフィックスは連続していますが、累積的ではありません。

他のすべての場合、穴の接頭辞の間に、それを書き留める必要があります。

既製のソリューションを探していませんでした。おそらくipaddressを使用しても同じことができます。 私の実装では、スタックがメインの作業ツールとして使用されます。

for line in fileinput.input(): prefix = ipv4num(line) while len(ipstack): cur_prefix = ipstack.pop() sum_prefix = netsum(cur_prefix, prefix) if sum_prefix[0]: prefix = sum_prefix continue elif issubnet(cur_prefix, prefix): prefix = cur_prefix break elif isseq(cur_prefix, prefix): if prefix[1] <= cur_prefix[1]: ipstack[:] = [] break else: ipstack.append(cur_prefix) break else: for gapprefix, mask in subnets(cur_prefix[0] + ipaddrcount(cur_prefix[1]), prefix[0]): print "{}/{}".format(numipv4(gapprefix), mask) ipstack[:] = [] break ipstack.append(prefix) 

コード全体をGithubで取得できます。

入力で受信したプレフィックスは、上記の3つの条件のいずれかのスタックが満たされているという事実と比較されます。

1. プレフィックスが合計される場合、合計を実行し、スタックの一番下に移動し続けます。既に合計されたプレフィックスと、再び合計できることを期待して上から取られた新しいプレフィックスを比較します。
2. スタックのプレフィックスに入力のプレフィックスが含まれている場合、入力の次のプレフィックスに移動し、チェックされたプレフィックスをスタックの最上部に返します。
3. プレフィックスが次々に移動し、入力からのプレフィックスマスクがスタックから取得されたものよりも長い場合、新しいプレフィックスを先頭に配置します（将来、入力からの他のプレフィックスと合計できます）。 マスクがそれより短いか等しい場合、以前のスタック全体を保持することは意味がありません。どの場合でも、それ以降のすべてのチェックは新しいプレフィックスのみで行われるためです。 スタックをクリアし、受け取った値を一番上に置きます。

このいずれも発生しない場合は、便宜上、間隔の開始アドレスと終了アドレスを計算し、プレフィックス表記に変換します。

BPGを完全に表示するためだけに残ります。 手元にある最も近いBGPルーターを使用することは可能ですが、誰もがそのような機会を持っているわけではありません。 したがって、ここからデータを取得しますwww.routeviews.org-優れた研究、学術リソース。 インターネットルーティングテーブルがかなりの期間収集されるデータを含むアーカイブ自体は、ここarchive.routeviews.org/oix-route-viewsにあります。 4月20日のファイルを選択しました。

テーブルは、プライベートアドレス空間のアドレスと/ 32アドレスで少しノイズが多くなります。 したがって、すべてが接頭辞/ 24（実際の現実に対応する）にフィルターされ、繰り返される接頭辞が削除されました。 このために特別に発明されたものはありません-grepおよびuniqツールが使用されました。 10分間の最長プロセスでした。

その結果、元のテーブルには628105個のプレフィックスが含まれ、それらの半分以上は344704が/ 24を占めています。 私の意見では、不足の結果としてのアドレス不足の良い指標は、アドレス空間の断片化です。 8697のプレフィックスはRIRの管理下になく、RIRの形成前にプレフィックスを受け取った組織に属します。 表16で発表されている最短のプレフィックス/合計8、そのうち13はRIRの管轄ではありません。


_{レガシー-RIRの管理下にないアドレス。}


ルーティングテーブルには、交​​差するプレフィックスが含まれています。 一部のデータを取得するには、さらに深くする必要があります。 これは行いません。ルーティングされないアドレスの数を計算することは、はるかに興味深いことです。

スクリプトを実行して結果を取得します。 この前から、プライベートアドレススペースのプレフィックスは元のテーブルからクリアされ、いくつかの特別なアドレスが再び表示されましたが、既にルーティング不可能なテーブル（プログラムの正しい動作を確認します）にありました。 再び掃除します。 それらを考慮に入れることは意味がありません-ほとんどの場合、ルーティングに使用されることはありません。 すべてのアドレスの1/16が固定されているブロック240.0.0.0/4に注意を向けます。

残っているアドレス空間のうち、合計79ブロック/ 8でルーティングされません。 ARINは39、APNIC 12、およびRIPE 7を占めます。実際、これから2番目のインターネットを構築できます。 RIPEは、未割り当てブロック/ 8についてのみ報告することを思い出してください 。





ルーティング不可能な最大ブロックは28.0.0.0〜30.255.255.255です。 このドキュメントによって判断される2つの組織、 DSI-NorthおよびDefense Information Systems Agencyに属します。

RIRの管理下にあるアドレスブロックは、事後にそれらを取得する可能性があることに注意してください。 たとえば、ARINによって管理されるブロック7.0.0.0/8は、 whois ARINによって判断されるDoD Network Information Centerによって完全に所有され、ルーティングされません。 このようなブロック内のアドレスの総数は、接頭辞/ 8が付いた約42個のアドレススペースに対応します。

たとえば、 13.128.0.0 / 9や29.0.0.0/8などの連続したブロックには、inetnumおよびrouteオブジェクトが分散されていることがありますが、それでもグローバルには何も見られないことがあります。

場合によっては、会社には2.0.0.0/12などの大きな連続ブロックがありますが、明らかに無用であるため、このブロックの一部のみを発表しています。 ギャップは2.7.0.0/16および2.15.0.0/16で取得されます。 些細なことかもしれませんが、空きアドレスのピークは/ 16です。

少し振り返って2011年4月20日のデータを取得すると、次の図が表示されます。





より多くのアドレスがあり、全体のほぼ3分の1でした。 この間、すべてのRIRはアドレスをあまり使用せず、一部はLACNICのように非常に多く使用しましたが、一般的には1/3から半分に費やしました。 直接管理されていないRIRアドレスは、現状のままであり、実際には完全に有効であることがわかります。 それどころか、一部のアドレスは解放されます。 インターネットの形成の夜明けには、まだ使用されていないすべてのアドレスの5分の1が配布されたことがわかりました。 より正確には、これらはローカルのどこかで使用できますが、実際にはBGPインターネットアクセスは存在しません。

BGPのフルビューでは、それほど多くのアドレスが表示されないことを期待していませんでした。 それらの多くは誰かに割り当てられましたが、まったく使用されていません。 もちろん、これは私を混乱させ、私は自分が間違っていた場所を探し始めました。 私は真剣に繰り返し繰り返しミスをしましたが、すべての修正を行った後、最終結果はあまり変わりませんでした。 たぶんすべてを見つけられなかったか、間違っていると思う。 最終的には、AFRINICに対応するすべてのブロックを手動でチェックして、BGPルーターのルーティングテーブルに存在するかどうかを確認し、少なくともこの場合は正しいと見なされるようにしました。

ルーティングテーブルの空きブロックをRIRベースと比較するという、あまりにも多くのアドレスを比較するという元のアイデアを放棄しなければなりませんでした。 受信したすべてのダンプを、プレフィックスのリスト内のスペースを計算するスクリプトの隣に配置します 。計算を繰り返すようにみんなに勧めます。 その間、私たちは開拓者にat望の念を抱いています。開拓者は、近い将来ではなく、確かにアドレスの不足によって脅かされていません。 調査は適切です：