[189998] in North American Network Operators' Group
Re: Netflix banning HE tunnels
daemon@ATHENA.MIT.EDU (Owen DeLong)
Sun Jun 12 20:05:21 2016
X-Original-To: nanog@nanog.org
From: Owen DeLong <owen@delong.com>
In-Reply-To: <156713.1465547545@turing-police.cc.vt.edu>
Date: Sun, 12 Jun 2016 17:05:17 -0700
To: Valdis.Kletnieks@vt.edu
Cc: nanog@nanog.org
Errors-To: nanog-bounces@nanog.org
> On Jun 10, 2016, at 01:32 , Valdis.Kletnieks@vt.edu wrote:
>=20
> On Fri, 10 Jun 2016 07:19:22 +0100, "tim@pelican.org" said:
>=20
>> All the business systems that sit around it? Not so much. $DAYJOB =
has
>> plenty of code, database structures etc that are built around "an IP =
address is
>> no more than 15 characters long and matches
>> '[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}'". To fix that, you =
need
>> development time - typically expensive analyst time to work out =
*what* you need
>> to change, not just code-grinder make-the-field-bigger time. IT =
departments
>> seem reluctant to provide that resource, unless you've got people at =
the very
>> top of the business bought into the fact that you *need* to do IPv6.
That was a pretty dumb way to store IPv4 addresses, frankly.
First, 593.812.904.601 matches your regular expression, and isn=E2=80=99t =
an IP address.
If you were smart (IMHO), you stored IPv4 addresses as 32-bit integers.
First, update the software in question to understand IPv4 mapped =
addresses for parsing/displaying (IPv4->::ffff:i.p.v.4 for parsing and =
reverse the process for display) and then modify the database schema.
With most databases and other software, converting a 32-bit integer =
field into a 128 bit integer field isn=E2=80=99t particularly hard.
Once you=E2=80=99ve done that, make a quick single pass through the =
database adding 281,470.681.743.360 to all integers < 4,294,967,296.
(That should replace the equivalent of 0:0:0:0:0:0:ip:v4 with the =
equivalent of 0:0:0:0:0:ffff:ip:v4)
There are a number of reasons for converting all IP addresses to =
integers prior to processing in software.
1. Easier and more consistent sorting.
2. Consistent and easier comparisons for equality or ranges
In iPv4, this was useful. In IPv6, it=E2=80=99s =
essential.
e.g.
IPv4: 90.90 =3D=3D 90.0.0.90
IPv4: 33280.33288 =3D=3D 130.0.130.8
IPv6: All of the following are equal
2001:db8::3
2001:0db8::0003
2001:0db8:0:0:0:0:0:3
2001:db8:0::3
etc.
Also:
2620::930:0:0:0:200:2
2620:0:930::200:2
etc.
3. Easier to deal with future changes (such as expanding from =
32-bit IPv4 numbers to 128-bit IPv6 numbers)
4. Representation can be left to the user interface where it =
belongs instead of embedded throughout the application.
The network stack only deals with integers, why not keep them as =
integers everywhere else as well. The other
expressions are just for human readability. Treat them like any =
other Locale based UI issue.
Yes, you need to get the people at the top bought into the idea that =
IPv6 must be deployed, but these days, that really shouldn=E2=80=99t be =
all that hard to do with competent management and a reasonable =
networking department.
Owen
