"Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications"....

Fri Nov 30 14:45:25 UTC 2012

I'll see your disagree and raise you another ;-)

I would say you almost never want to store addresses as character data
unless the only thing you're using them for is logging (even then it's
questionable).  I run into people who do this all the time and it's a
nightmare.

It's easy to store a v6 address as a string, but when you want to select a
range of IPv6 addresses from a database, not having them represented as
integers means you can't do efficient numerical comparisons in your SQL
statements, it also makes indexing your table slower; to put it simply, it
doesn't scale well.

So as a general rule, if you need to do any comparison or calculation on a
v6 address, please don't store it as a string.

>From an efficiency standpoint, you want to store it in chunks of the
largest integer your DBMS supports.  If a DBMS supports 128-bit integers
and has optimized operations for them, then go for it.  Most only support
64-, or even 32-bit.  I say 64-bit because that's what the majority of
current systems actually support and I don't see anyone coming out with a
128-bit architecture ;(

For convenience I would very much love to see MySQL include inet6_aton and
inet6_ntoa, along with a 128-bit data structure that would
be implemented as either a pair of 64-bit or 4x 32-bit values depending on
the architecture.  But from a performance standpoint, I really don't want
my DBMS doing that calculation; I want the application server doing it
(because it's much easier to scale and distribute the application side than
the storage side).

Note that I'm talking about more from a database storage perspective than
an internal application perspective.

By all means, you should use the standard data structure for v6.  As
mentioned below a lot of the internal structures use 8-bit unsigned
integers (or char); but that's mainly a hold-over from when we had the
reality of 8-bit and 16-bit platforms (for compatibility).  With unions,
these structs are treated as a collection of 8, 16, 32, 64 or a single
128-bit variable which makes it something the developer doesn't need to
worry about once the libraries are written.

On Thu, Nov 29, 2012 at 9:55 AM, William Herrin <bill at herrin.us> wrote:

> On Thu, Nov 29, 2012 at 9:01 AM, Ray Soucy <rps at maine.edu> wrote:
> > You should store IPv6 as a pair of 64-bit integers.  While PHP lacks
> > the function set to do this on its own, it's not very difficult to do.
>
> Hi Ray,
>
> I have to disagree. In your SQL database you should store addresses as
> a fixed length character string containing a zero-padded hexadecimal
> representation of the IPv4 or IPv6 address with A through F forced to
> the consistent case of your choice. Expand :: and optionally strip the
> colons entirely. If you want to store a block of addresses, store it
> as two character strings: start and end of the range.
>
> Bytes are cheap and query simplicity is important. Multi-element
> indexes are messy and the code to manage an array of integers is
> messier than managing a character string in most programming
> languages. memcmp() that integer array for less or greater than? Not
> on a little endian machine!
>
>
> > Here are a set of functions I wrote a while back to do just that
> > (though I admit I should spend some time to try and make it more
> > elegant and I'm not sure it's completely up to date compared to my
> > local copy ... I would love some eyes on it to make some
> > improvements).
> >
> > http://soucy.org/project/inet6/
>
> If we're plugging our code, give my public domain libeasyv6 a try. It
> eases entry into dual stack programming for anyone used to doing
> gethostbyname followed by a blocking connect(). Just do a
> connectbyname() with the hostname or textual IP address, the port, a
> timeout and null options. The library takes care of finding a working
> IPv4 or IPv6 address for the host and connecting to it in a timely
> manner.
>
> http://bill.herrin.us/freebies/
>
> Currently Linux only but if you're willing to lose timeout control on
> the DNS lookup you can replace getaddrinfo_a() with standard
> getaddrinfo() and the code should run anywhere.
>
> Regards,
> Bill Herrin
>
>
> --
> William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
> 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
> Falls Church, VA 22042-3004
>

-- 
Ray Patrick Soucy
Network Engineer
University of Maine System

T: 207-561-3526
F: 207-561-3531

MaineREN, Maine's Research and Education Network
www.maineren.net