[158307] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

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

daemon@ATHENA.MIT.EDU (Owen DeLong)
Tue Nov 27 22:41:13 2012

From: Owen DeLong <owen@delong.com>
In-Reply-To: <01db01cdcd17$1d0e7100$572b5300$@iname.com>
Date: Tue, 27 Nov 2012 19:38:22 -0800
To: "Dave Edelman" <dedelman@iname.com>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org


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

> I think that we are missing a significant part of this conversation.=20=

>=20
> 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.
>=20

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 =3D 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.
>=20

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

>=20
> --Dave
>=20
>> -----Original Message-----
>> From: Owen DeLong [mailto:owen@delong.com]
>> Sent: Tuesday, November 27, 2012 6:48 PM
>> To: Jared Mauch
>> Cc: nanog@nanog.org
>> Subject: Re: "Programmers can't get IPv6 thus that is why they do not =
have
>> IPv6 in their applications"....
>>=20
>>>=20
>>>> 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.
>>>=20
>>> Sure, using gethostbyname() is certainly easier to find code =
examples,
> but
>> not impossible to find other examples.
>>>=20
>>=20
>> http://owend.corp.he.net/ipv6
>>=20
>> Pretty much everything you need to know about taking your =
applications
>> from mono-stack to dual-stack.
>>=20
>> Includes an example application implemented in IPv4 only and ported =
to
> dual
>> stack in C, PERL, and Python.
>>=20
>>>> 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.
>>>=20
>>> 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.
>>>=20
>>=20
>> It's actually pretty easy to change the datatype in an SQL database, =
so
> that
>> shouldn't be that much of an impediment.
>>=20
>> Owen
>>=20
>=20



home help back first fref pref prev next nref lref last post