Re: [Sqlgrey-users] SQLgrey and IPv6

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

Klaus Alexander Seistrup wrote the following on 06.03.2005 13:12 :

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

I'm not sure IPv6/64 is the same as IPv4/32, I'll ask around as I know 
some ADSL users with IPv6 connectivity. My ideas on the subject should 
be clear before I step into IPv6 territory especially since I've no 
access to IPv6 for testing purposes myself.

One more thing: I need to know who will be able to test IPv6 support 
(I'm not able to). For testing, you'll need at least a Postfix 2.2 
pre-release (not a Postfix with an unofficial IPv6 patch...) or 2.2.x 
when it's out and some IPv6 SMTP trafic.

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

In the example "2001:4f8:3:ba:2e0:" wasn't meant to be an IPv6 address 
but the result of SQLgrey "client identifier" computation. For IPv4 
addresses it currently removes everything after the last ".", including 
the "." character itself.

What I wanted to say is that if it simply removes everything after the 
last ":" in the IPv6 case and "2001:4f8:3:ba:2e0::" is a valid IPv6 
address I'm expecting problems. On second thought the solution for this 
is obvious, just remove whatever comes after the ":" but don't remove 
the ":" character itself. I'm still wondering if there are some nasty 
things around I'm not expecting though.

Lionel.