[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
"Programmers can't get IPv6 thus that is why they do not have IPv6 in their applications"....
Why would I want to do that instead of store it as a single 128 bit integer or bit-field?
Sent from my iPad
On Nov 29, 2012, at 6: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.
> 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
> 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
> 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
> 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
> On Thu, Nov 29, 2012 at 8:15 AM, Jeroen Massar <jeroen at unfix.org> wrote:
>> On 2012-11-29 13:53 , . wrote:
>>> On 29 November 2012 12:48, Dobbins, Roland <rdobbins at 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.
>> 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? :)
> Ray Patrick Soucy
> Network Engineer
> University of Maine System
> T: 207-561-3526
> F: 207-561-3531
> MaineREN, Maine's Research and Education Network