Why would I want to do that instead of store it as a single 128 bit integer or bit-field?
Owen Sent from my iPad On Nov 29, 2012, at 6:01 AM, Ray Soucy <r...@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. > > 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. > > 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. > > > > > On Thu, Nov 29, 2012 at 8:15 AM, Jeroen Massar <jer...@unfix.org> wrote: >> On 2012-11-29 13:53 , . wrote: >>> On 29 November 2012 12:48, Dobbins, Roland <rdobb...@arbor.net> wrote: >>>> >>>> On Nov 29, 2012, at 6:47 PM, Bjørn Mork wrote: >>>> >>>>> What's the proper term for software which happens to access the network? >>>> >>>> Just about anything, these days. >>>> >>>> ;> >>>> >>>> 'Network-enabled' or 'network-capable' software, maybe? >>> >>> Connecting a app to a network is a fundamental change, so perhaps >>> change the app to become a "network app". A piece of software >>> connected to a network turns from a product into a service. >>> >>> "Programmers" is to a wide group of people. I am PHP programmer. How >>> will ipv6 impact me? nothing, probably. >> >> *ahem* >> >> As Owen already alluded to, some programs (PHP also) actually store IP >> addresses in databases. Thus if you where storing those as 32bit, you >> are out of luck. >> >> [..] >>> There are two groups of programmers, a) these that have programming >>> only as a job, and b) these that invest time beyond that. >> >> Group a for you? :) >> >> Greets, >> Jeroen > > > > -- > 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
