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

Wed Nov 28 03:38:22 UTC 2012

On Nov 27, 2012, at 19:18 , "Dave Edelman" <dedelman at iname.com> wrote:

> I think that we are missing a significant part of this conversation. 
> 
> Even if programmers never write a line of code that invokes IPv6, they need
> to accommodate the effects of all the other programmers who aren't writing a
> line of IPv6 code. CGN renders most application logs useless unless they
> record source port as well as address. For many industries, logging of
> transactions in a manner that allows you to track back to the originator of
> the transaction is not optional. And yes that does translate to track back
> to the ISP who (when presented with the appropriate piece of paper) can
> convert the timestamp /IP address/ port combination to the customer who is
> responsible for the account.
> 

That won't help. Think about it this way. A session state log entry is roughly 512 bytes.

I'm told (by several of the large residential providers) that the average session rate per
subscriber is around 33,000 connections/subscriber/day for roughly 17Kbytes/day of
log entries per day.

Take a carrier like Comcast that has ~20,000,000 subscribers. That's 660,000,000,000
or 660 Terabytes per day of log files. Now, imagine trying to keep that data set for
7 years worth of data. That's a 660*365*7 = 1,686,300 Terabyte (or 1.7 Exabyte)
storage array. I'm sure EMC would love to build something like that, but, I'm willing
to bet that any economic analysis of that problem against CALEA reveals the
relatively swift conclusion that the fines cost less than the infrastructure to preserve
the logs.

Even if you can cut the session state log entry down to 26 octets (which is only
room for 2xSource IPv4 address, 1x destination IPv4 address, 2x Source port#,
1x destination port#, a 32-bit timestamp and a 32-bit subscriber ID), you're still
looking at roughly 85 Petabytes of storage required to meet CALEA standards.

This doesn't account for the additional costs involved in managing that kind of
logging infrastructure, etc.

> Even if programmers never write a line of code that invokes IPv6, they had
> better be testing their Internet facing applications against users in pure
> IPv4 environments; users in pure IPv6 environment using each of  the
> transition mechanism, and users in dual-stack environments.
> 

That would be ideal, but if they aren't writing any IPv6 code, they probably lack
the understanding required in order to do so.

> I've spent more than a small amount of time explaining to vendors that
> AI_ADDRCONFIG is a really good hint flag to have set. One vendor responded
> that the change would require retesting everything. I'm afraid that he
> wasn't happy when I pointed out that they obviously hadn't tested the first
> time and that as the customer, I was entitled to at least one full set of
> (successful)  pre-delivery testing.

ROFL

Owen

> 
> --Dave
> 
>> -----Original Message-----
>> From: Owen DeLong [mailto:owen at delong.com]
>> Sent: Tuesday, November 27, 2012 6:48 PM
>> To: Jared Mauch
>> Cc: nanog at nanog.org
>> Subject: Re: "Programmers can't get IPv6 thus that is why they do not have
>> IPv6 in their applications"....
>> 
>>> 
>>>> I agree that some of it comes down to knowledge; most programmers
>>>> learn from experience and lets face it unless you go looking your
>>>> unlikely to run into IPv6 even as of yet. I believe as the ISP
>>>> implements IPv6 and companies get more demand on the customer facing
>>>> side of things it will pick up quickly.
>>> 
>>> Sure, using gethostbyname() is certainly easier to find code examples,
> but
>> not impossible to find other examples.
>>> 
>> 
>> http://owend.corp.he.net/ipv6
>> 
>> Pretty much everything you need to know about taking your applications
>> from mono-stack to dual-stack.
>> 
>> Includes an example application implemented in IPv4 only and ported to
> dual
>> stack in C, PERL, and Python.
>> 
>>>> In our datacenters all our software is built with IPv6 addressing
>>>> supported but we have yet to build the logic stack as we are waiting
>>>> for the demand. It makes no sense to build all the support just
>>>> because when there are other important things to do.
>>> 
>>> There is something else.  Many people "cheated" and stuck a 2^32 number
>> in an integer datatype for their SQL or other servers.  They don't work as
> well
>> with 2^128 sized IPs.  They have to undertake the actual effort of storing
>> their data in a proper datatype instead of cheating.  I've seen this
> over-and-
>> over and likely is a significant impediment just as the gethostbyname vs
>> getaddrinfo() system call translations may be.
>>> 
>> 
>> It's actually pretty easy to change the datatype in an SQL database, so
> that
>> shouldn't be that much of an impediment.
>> 
>> Owen
>> 
> 