Re: [Maria-developers] Ipv6

2010-08-24 Thread Jocelyn Fournier

 Hi,

ipv6 INET_ATON and INET_NTOA would be mainly usefull to application 
compatibility, and painless ipv6 migration.


For example, in my PHP script I'm using almost everywhere INET_ATON to 
store $_SERVER['REMOTE_ADDR'].
If INET_ATON and NTOA are supported, I only have to change the column 
type storing my IP values to be able to store 128-bit integers, without 
changing anything else in the code.


Thanks,
  Jocelyn


Le 23/08/2010 18:53, Sergei Golubchik a écrit :

Hi, Jocelyn!

On Aug 23, Jocelyn Fournier wrote:

Hi Sergei,

What about INET_ATON / INET_NTOA ipv6 support ?
(there's a feature request opened on mysql since jan 2008 :
http://bugs.mysql.com/bug.php?id=34037 )

They would need to convert to and from DECIMAL.
It's doable.

If you mean 128-bit integers, adding them is more complex, I guess, than
adding a native ipv6 type (which is implemented on top of binary(16)
internally).

Why one would need INET_NTOA6 and INET_ATON6 ?

INET_ATON can be used to convert an ip address to store it in the table,
to save storage space.

INET_ATON can be used to convert an ip address to a number to check
against a subnet mask.

Anything else ?

Because if there is IPv6 native type there will be no need to convert
for storage and no need to convert for a mask check.

Regards,
Sergei

___
Mailing list: https://launchpad.net/~maria-developers
Post to : maria-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-developers
More help   : https://help.launchpad.net/ListHelp



___
Mailing list: https://launchpad.net/~maria-developers
Post to : maria-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Maria-developers] Ipv6

2010-08-23 Thread Sergei Golubchik
Hi, Jocelyn!

On Aug 23, Jocelyn Fournier wrote:
>
> Hi Sergei,
>
> What about INET_ATON / INET_NTOA ipv6 support ?
> (there's a feature request opened on mysql since jan 2008 : 
> http://bugs.mysql.com/bug.php?id=34037 )

They would need to convert to and from DECIMAL.
It's doable.

If you mean 128-bit integers, adding them is more complex, I guess, than
adding a native ipv6 type (which is implemented on top of binary(16)
internally).

Why one would need INET_NTOA6 and INET_ATON6 ?

INET_ATON can be used to convert an ip address to store it in the table,
to save storage space.

INET_ATON can be used to convert an ip address to a number to check
against a subnet mask.

Anything else ?

Because if there is IPv6 native type there will be no need to convert
for storage and no need to convert for a mask check.

Regards,
Sergei

___
Mailing list: https://launchpad.net/~maria-developers
Post to : maria-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Maria-developers] Ipv6

2010-08-23 Thread Jocelyn Fournier

  Hi Sergei,

What about INET_ATON / INET_NTOA ipv6 support ?
(there's a feature request opened on mysql since jan 2008 : 
http://bugs.mysql.com/bug.php?id=34037 )


Thanks,
  Jocelyn



Le 23/08/2010 15:47, Sergei Golubchik a écrit :

Hi, Dolf!

On Aug 23, Dolf Schimmel wrote:


My proposal would be to introduce two new datatypes, one for 128bit
integers, and one extending the 128bit integer type for ipv6
addresses. Meaning that the latter accept ipv6 addresses only, but
relies on the first one for storing it, and displaying it again as
ipv6 address.

With ipv6 one usually will do much more rangechecks than ipv4 because
with ipv6 residential homes simply get a /64 block (2^(128-64)= a lot
of addresses) instead of simply one address.  Therefore a nice feature
would be to allow queries like: `SELECT * FROM table WHERE columnName
IN 2001:db8:85a3::8a2e:370:7334/62` which essentially would select all
rows where columnName is in the same /64 block as
2001:db8:85a3::8a2e:370:7334 is.

I'm a simple PHP developer so I can't supply a patch, but I would be
really curious in what you think about the above, and hope someone is
able and willing to pick it up.

This looks moderately easy to do. Without 128-bit integers, at least.
But you don't need them, as far as I understand, who needs math
operations on ipv6 addresses.

Making MySQL to use indexes for selects like in your example would be a
bit more involved, but still doable.

If, indeed, "someone is able and willing to pick it up", I could help
this someone to understand what to change, where, and how.

Regards,
Sergei

___
Mailing list: https://launchpad.net/~maria-developers
Post to : maria-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-developers
More help   : https://help.launchpad.net/ListHelp



___
Mailing list: https://launchpad.net/~maria-developers
Post to : maria-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-developers
More help   : https://help.launchpad.net/ListHelp


Re: [Maria-developers] Ipv6

2010-08-23 Thread Sergei Golubchik
Hi, Dolf!

On Aug 23, Dolf Schimmel wrote:

> My proposal would be to introduce two new datatypes, one for 128bit
> integers, and one extending the 128bit integer type for ipv6
> addresses. Meaning that the latter accept ipv6 addresses only, but
> relies on the first one for storing it, and displaying it again as
> ipv6 address.
>
> With ipv6 one usually will do much more rangechecks than ipv4 because
> with ipv6 residential homes simply get a /64 block (2^(128-64)= a lot
> of addresses) instead of simply one address.  Therefore a nice feature
> would be to allow queries like: `SELECT * FROM table WHERE columnName
> IN 2001:db8:85a3::8a2e:370:7334/62` which essentially would select all
> rows where columnName is in the same /64 block as
> 2001:db8:85a3::8a2e:370:7334 is.
> 
> I'm a simple PHP developer so I can't supply a patch, but I would be
> really curious in what you think about the above, and hope someone is
> able and willing to pick it up.

This looks moderately easy to do. Without 128-bit integers, at least.
But you don't need them, as far as I understand, who needs math
operations on ipv6 addresses.

Making MySQL to use indexes for selects like in your example would be a
bit more involved, but still doable.

If, indeed, "someone is able and willing to pick it up", I could help
this someone to understand what to change, where, and how.
 
Regards,
Sergei

___
Mailing list: https://launchpad.net/~maria-developers
Post to : maria-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-developers
More help   : https://help.launchpad.net/ListHelp


[Maria-developers] Ipv6

2010-08-23 Thread Dolf Schimmel
Dear Folks,

With 5 billion devices connected on the internet, and only a total of
4 billion ip(v4) addreses, available ipv4 addresses are becoming more
and more scarcely. Latest estimates are that it will take less than a
year before IANA has no more ipv4 addresses to distribute to LIR's
(APNIC, RIPE, etc), and some time after that it will be really, really
difficult for anybody to get an ipv4 address. Luckily there's a
solution for that in the form of ipv6. Ipv6 is very common in certain
parts of Asia (Japan) where students are only given a block of ipv6
addresses with a mere tunnel to access ipv4 hosts. In France one of
the biggest ISP's ( http://free.fr ) is giving every residential dsl
connection a block of ipv6 addresses, and in The Netherlands more and
more shared webhosters assign each individual website its own ipv6
address (obviously together with a shared ipv4 address) since Direct
Admin ( http://directadmin.com competitor of cpanel and plesk) fully
supports ipv6. All in all, the world is calling for ipv6 and products
that suppoort it.

Whereas ipv4 is 32bit, resulting in a total number of 2^32 (=4billion)
ip's, ipv6 is 128bit, giving 2^128 addresses. A number large enough
for me not to spell it out for you :D Though an ipv6 address does have
several hexadecimal notations, it still simply is a 128bit unsigned
integer. And as such, I'm sending this email requesting to support it.
My proposal would be to introduce two new datatypes, one for 128bit
integers, and one extending the 128bit integer type for ipv6
addresses. Meaning that the latter accept ipv6 addresses only, but
relies on the first one for storing it, and displaying it again as
ipv6 address. With ipv6 one usually will do much more rangechecks than
ipv4 because with ipv6 residential homes simply get a /64 block
(2^(128-64)= a lot of addresses) instead of simply one address.
Therefore a nice feature would be to allow queries like: `SELECT *
FROM table WHERE columnName IN 2001:db8:85a3::8a2e:370:7334/62` which
essentially would select all rows where columnName is in the same /64
block as 2001:db8:85a3::8a2e:370:7334 is.

I'm a simple PHP developer so I can't supply a patch, but I would be
really curious in what you think about the above, and hope someone is
able and willing to pick it up.

Regards,

Dolf Schimmel
-- Freeaqingme

P.s. I'm sorry if the first paragraph is stating the obvious only.
Some people know everything about ipv6, and some don't at all. Which
is why I figured an introduction wouldn't hurt.

___
Mailing list: https://launchpad.net/~maria-developers
Post to : maria-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-developers
More help   : https://help.launchpad.net/ListHelp