2009-04-21 6 views
5

От this post Меня интересует диапазон адресов IPv6.Диапазон адресов IPv6

В соответствии с IPv4 я мог бы определить начальный и конечный IP-адреса, предоставляемые ISP, и использовать эти целочисленные значения, поскольку границы диапазона быстро ищут базу данных, чтобы узнать, попали ли какие-либо записи в БД в этот диапазон.

Как это повлияет на IPv6? Будет ли у ISP по-прежнему иметь IPv6-адреса в диапазонах, как сейчас? И как бы вы эффективно искали эти диапазоны, если бы вы хранили адреса IPv6 в виде двух bigint в базе данных SQL Server?

+0

Следующая нить была предложена [@vinS] (https://stackoverflow.com/users/977855/vins) в качестве решения IPv6 вашего вопроса: https: //stackoverflow.com/questions/53497/regular-expression-that-matches-valid-ipv6-addresses – datv

ответ

8

Неправильно использовать IP-адреса (ни IPv4, ни IPv6) в диапазонах. Правильный способ группировки определенного «диапазона» IP-адресов - это использовать префиксы (нотации CIDR) или маски (устаревшие, действительные только для IPv4, а безумие возникает, если вы пытаетесь использовать несмежную маску).

Иногда вы можете увидеть кого-то (иногда даже приложения, домашние маршрутизаторы и т. Д.), Используя диапазоны IPv4, но это только неправильный способ сделать это.

Использование Classless Inter-Domain Routing (CIDR) вы будете иметь кортеж < адрес, префикс >, где адрес является 128-разрядным целым числом без знака и префикс крошечного (0..128) целого числа без знака. Префикс указывает, сколько наиболее значимых битов адреса представляет сетевой адрес, оставляя младшие младшие биты 128-префикса для представления определенного хоста в этой сети.

Так, например, «диапазон» IPv6 2620: 0: 860: 2 ::/64 (wikimedia.org) представляет все хосты от 2620: 0: 860: 2 :: до 2620: 0: 860: 2: FFFF: FFFF: FFFF: FFFF.

Вам не следует использовать два «bigint» для хранения такого значения в базе данных, но использовать любое собственное представление в одном столбце, если вы не хотите, чтобы ваш разработчик стал кошмаром. Если ваша СУБД не поддерживает целые числа, это большое, помимо замены СУБД, я предлагаю использовать столбец двоичных данных фиксированного размера длиной 16 байт.

4

Использование СУБД с надлежащей поддержкой адресов IPv6 не будет плохой идеей . Вот пример с 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) 
+1

Хороший подвиг для PostgreSQL. Если бы только переключение СУБД было так же просто, как хлопать в ладоши :) –