Re: [Sqlgrey-users] SQLgrey and IPv6

[Lionel B. <lio...@bo...>]

Klaus Alexander Seistrup wrote the following on 06.03.2005 11:22 :

>On Sun 19 Dec 2004, Lionel Bouton <lio...@bo...> wrote:
>
>  
>
>>What I can do is changing the table layouts in 1.5.x to handle the
>>maximum IPv6 address representation size (39 bytes).
>>    
>>
>
>Any news about the IPv6 issue?  I'm running SQLgrey v1.5.1, and the
>table layout still uses 15 charcters for storing IP addresses.
>
>  
>

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

It still will be tricky to handle. I need to learn a few things about 
IPv6 beforehand:

- what's the longest representation of an IPv6 address again?
- 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?
- 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?).

 From my reading of the Postfix documentation, we can at least rule out 
the programmer's nightmare of IPv4 in IPv6 addresses representations 
("::101.45.23.74" is a valid IPv6 address).

>Some time ago I switched from SQLite to PostgreSQL.  Any chance to
>have SQLgrey use the INET storage type if database is PostgreSQL?
>  
>

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.

If INET proves to be useful it will probably be by allowing to handle 
some computations inside the database, it won't happen without a lot of 
code being reengineered for PostgreSQL. SQLgrey will probably have to 
fork into SQLgrey-generic and SQLgrey-PostgreSQL to make it easier to 
maintain.

VARCHAR is probably less efficient than INET, but probably not enough to 
have PostgreSQL specific code.
I'm not even sure that the performance difference will be measurable. 
INET is a complex storage type compared to VARCHAR, it must probably 
make provisions to store the type (IPv4/IPv6) and does store the network 
too -> it will use at least 17 bytes, probably more. On the other hand a 
VARCHAR IPv6 representation of an IPv4 address - the typical case - 
should be less than 20 bytes.

>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.
>
>  
>

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.

IPv6 in TODO.

Lionel.