In message <CALFTrnM+a56hx3CP0qqszfNrbirQZOefS_0uHVC8VQk=+QDC2g@mail.gmail.com> , Ray Soucy writes:
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.
I did it as a array of 8, 16 bit integers with a old version of dhclient. The had the advantage that you could just do "%x:%x:%x:%x:%x:%x:%x:%x" and get a valid IPv6 address which you could feed to other tools. option 6rd code 212 = { unsigned integer 8, unsigned integer 8, unsigned integer 16, unsigned integer 16, unsigned integer 16, unsigned integer 16, unsigned integer 16, unsigned integer 16, unsigned integer 16, unsigned integer 16, array of ip-address };
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/
I would point out that many developers don't even store IP addresses correctly and just treat them as a string. In regards to storing as a pair of 64-bit integers, I would caution against the temptation of treating one field as the prefix and the other as the host segment. While the 64-bit boundary is most common, it is certainly not required, so please write your IPv6 support in a way that will allow any valid prefix-length.
While PHP hasn't been my language of choice in the past, it seems to be something that almost everyone knows, or can learn very quickly. I've started using it as a command line scripting language quite a bit as a result ... pretty much a cleaner Perl, the upshot is that you don't have all the pre-written libraries that you'd find with Perl. I've tried switching to Python for some things, but I got annoyed with the specification being in a constant state of drastic syntax change.
But back to the topic at hand. I think the OP was expressing that until developers have native IPv6 access at home, they just won't care about IPv6 support, or won't test it as well as IPv4 support. That's pretty much expected and I'm not even sure why it's being stated as some revelation. As many have pointed out, there are tunnel brokers available to developers to test IPv6 with, but at the end of the day, most people don't want to use a slow tunnel for anything byond testing, and if they don't have a lot of users asking for IPv6 they're probably not going to give it much attention until they see a need for it.
It is a myth that tunnels are slow. They have to add some delay but depending upon the placement of the end point that may not even be measurable. I'm using one on another continent and for most of my traffic it has no measurable impact on the time. Some detinations are significantly worse. Tunneling with 6rd will generally not be measurable for any destination especially if you put the BR in the pop.
The majority of larger applications support IPv6 just fine because there are enough users asking for IPv6 support. I suspect once you see native IPv6 for residential users become more common you'll see the developers who have been dragging their feet give in and add IPv6 support.
As mentioned with a shift to web applications though the browser, it's been a lot less work. Just throw your application on a server with IPv6 and it will generally work. You might need to modify a few places that interact with IP addresses, but usually they're pretty trivial (like logging) unless it's a network management oriented application.
Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org