6

この投稿に続いて、IPv6 アドレス範囲の検索に興味があります。

IPv4 では、ISP から提供された開始 IP アドレスと終了 IP アドレスを特定し、それらの整数値を範囲の境界として使用して、データベースをすばやく検索し、DB 内のエントリがその範囲に該当するかどうかを確認できます。

これは IPv6 によってどのように影響を受けますか? ISP は、現在のように IPv6 アドレスを範囲内に保持する予定はありますか? また、IPv6 アドレスを 2 つの bigint として SQL Server DB に格納している場合、これらの範囲を効率的に検索するにはどうすればよいでしょうか?

4

2 に答える 2

8

範囲内で IP アドレス (IPv4 も IPv6 も) を使用するのは正しくありません。IP アドレスの特定の「範囲」をグループ化する正しい方法は、プレフィックス (CIDR 表記) またはマスク (廃止され、IPv4 でのみ有効であり、連続していないマスクを使用しようとすると狂気になります) を使用することです。

誰か (アプリケーションやホーム ルーターなど) が IPv4 範囲を使用しているのを時々見かけますが、それは単に間違った方法です。

Classless Inter-Domain Routing (CIDR)を使用すると、タプル <Address, Prefix> が得られます。ここで、Address は 128 ビットの符号なし整数で、Prefix は小さな (0..128) 符号なし整数です。プレフィックスは、ネットワーク アドレスを表すアドレスの最上位ビットの数を示し、残りの 128 プレフィックスの最下位ビットはそのネットワーク内の特定のホストを表します。

したがって、たとえば、2620:0:860:2::/64 (wikimedia.org) の IPv6「範囲」は、2620:0:860:2:: から 2620:0:860:2 までのすべてのホストを表します。 FFFF:FFFF:FFFF:FFFF.

そのような値をデータベースに格納するために 2 つの「bigint」を使用するべきではありませんが、開発者の生活を悪夢にしたくない場合を除き、1 つの列で任意のネイティブ表現を使用してください。お使いの DBMS がこれほど大きな整数をサポートしていない場合は、DBMS を置き換える以外に、16 バイト長の固定サイズのバイナリ データ列を使用することをお勧めします。

于 2009-04-21T23:14:18.390 に答える
4

IPv6アドレスを適切にサポートするDBMSを使用することは悪い考えではありません。PostgreSQLバージョン8.3の例を次に示します。

mydb=> CREATE TABLE Networks (name TEXT, prefix INET);
CREATE TABLE
mydb=> INSERT INTO Networks VALUES ('Documentation', '2001:DB8::/32');
INSERT 0 1
mydb=> INSERT INTO Networks VALUES ('ULA', 'FC00::/7');
INSERT 0 1
mydb=> INSERT INTO Networks VALUES ('Orchid', '2001:10::/28');
INSERT 0 1

mydb=> SELECT * FROM Networks;
 name      |    prefix     
---------------+---------------
 Documentation | 2001:db8::/32
 ULA           | fc00::/7
 Orchid        | 2001:10::/28
(3 rows)

mydb=> SELECT * FROM Networks WHERE '2001:DB8::dcaf:BAD' << prefix;
 name      |    prefix     
---------------+---------------
 Documentation | 2001:db8::/32
(1 row)
于 2009-04-22T20:25:29.240 に答える