Re: [Sqlgrey-users] SQLgrey and IPv6

[Klaus A. S. <kse...@gm...>]

Lionel Bouton wrote:

> Ooops, I forgot about IPv6. It seems as Postfix 2.2 is coming shortly
> with official IPv6 support we can now support it too.

:-)

> - what's the longest representation of an IPv6 address again?

1234:1234:1234:1234:1234:1234:1234:1234 =3D 39 characters

> - for 'smart' and 'classc', how do we compute the IPv6 network similar
> to the IPv4 "x.x.x.0/24" network? For the common case, is removing the
> last 32 bit hexadecimal component a good approach? Or are the IPv6
> addresses addresses distributed to end-users in a way that makes it
> possible to have wildly different systems in the same "/120" network?

I'm not sure.  Many tunnel brokers hand out /64 or /48 nets to end
users.  E.g., I have [2001:1448:89::]/48 from ngdc.dk.  My impression
is that IPv6/64 is somewhat similar to IPv4/32 (I'm not sure if
IPv6/48 should be compared to IPv4/24, though). but that is highly
subjective.

> - can we blindly remove the last :hexa component or are there
> compression tricks in the representation that will prevent this? i.e.:
>  . common case "2001:4f8:3:ba:2e0:81ff:fe22:d1f1" ->
> "2001:4f8:3:ba:2e0:81ff:fe22",
>  . imaginary problematic case: "2001:4f8:3:ba:2e0::" ->
> "2001:4f8:3:ba:2e0:" (can it happen?).

As far as I know, compression always involves "::", so
"2001:4f8:3:ba:2e0:" would never occur as shorthand for
"2001:4f8:3:ba:2e0::".
=20
>> Some time ago I switched from SQLite to PostgreSQL.  Any chance to
>> have SQLgrey use the INET storage type if database is PostgreSQL?
>=20
> In fact the original SQLgrey code used a PostgreSQL specific whitelist
> table using INET or CIDR. I removed this. I don't like database specific
> code. This make for more complex and less maintainable code.

Sure.
=20
> VARCHAR is probably less efficient than INET, but probably not enough to
> have PostgreSQL specific code.

I'm a lazy type of person, that's why I would like to use INET (or
CIDR) i SQLgrey.  The storage type handles IPv4 and IPv6 addresses
transparently, and it is very easy to test if a given IP address
belongs to a network ("SELECT foo FROM bar WHERE ip <<
'2001:1:2::/48'").

>> Would it be worth the trouble to put database specific rutines in
>> separate perl scripts, each having a similar API?  E.g. mysql-api.pm,
>> postgres-api.pm, sqlite-api.pm, ..., that each have a create_tables()
>> routine to create necessary tables.
>=20
> Probably not at this point. This could be used to avoid forking SQLgrey
> to support database specific code but you'll probably end with 90% of
> SQLgrey's code in the postgres-api.pm for example.

I see.

> IPv6 in TODO.

:-)

Cheers,

--=20
Klaus Alexander Seistrup
SubZeroNet =B7 Copenhagen =B7 Denmark