[Maria-developers] Ipv6
![](https://secure.gravatar.com/avatar/224e1cef5f377191a85019dd4b6dad31.jpg?s=120&d=mm&r=g)
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.
![](https://secure.gravatar.com/avatar/3c2329333dd5898f2e72818af773243d.jpg?s=120&d=mm&r=g)
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
![](https://secure.gravatar.com/avatar/b6a4a6527136d87b3f9682ddfcf80dbe.jpg?s=120&d=mm&r=g)
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
![](https://secure.gravatar.com/avatar/3c2329333dd5898f2e72818af773243d.jpg?s=120&d=mm&r=g)
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
![](https://secure.gravatar.com/avatar/b6a4a6527136d87b3f9682ddfcf80dbe.jpg?s=120&d=mm&r=g)
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
participants (3)
-
Dolf Schimmel
-
Jocelyn Fournier
-
Sergei Golubchik