nanog mailing list archives

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


From: Mark Andrews <marka () isc org>
Date: Fri, 30 Nov 2012 07:46:54 +1100


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


Current thread: