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

Thu Nov 29 20:46:54 UTC 2012

In message <CALFTrnM+a56hx3CP0qqszfNrbirQZOefS_0uHVC8VQk=+QDC2g at 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 at isc.org